Marc Glisse ha scritto:
I believe that the check for 0 in mpz_mul actually falls in your first category, it is necessary for correctness (however, mpz_mul also checks whether one of the arguments fits in a single limb, which fits your description better). And the else path is supposedly already heavy enough that the penalty should not be too bad. Did you see a significant performance gain using 2) instead of 3)?
It depends from data set and optimizations done inside the library: suppose we enter in mpz_mul 99% of the times with both operands below 1<<(sizeof(mp_limb_t)*4) and this is treated as a special case, then I think that to avoid two extra comparison can make a difference.
My point is that to maximize performance the unavoidable path should be the least computationally expensive.