(Related, I wonder what the effect would be of redefining umul_ppmm as C
expressions involving __uint128_t on compilers that support that).
We do that already for some CPUs, but this has proven to be somewhat
fragile, and in unexpected cases lead to libgcc calls.
We brave to do
ni...@lysator.liu.se (Niels Möller) writes:
Using inline asm instead has the drawback that it leaves a little less
opportunity for the compiler to schedule this instructions optimally. No
idea if that matters in practice. Since it seems we don't really need
count_*_zeros to support zero
t...@gmplib.org (Torbjörn Granlund) writes:
> We might define these directly, at least for arm64, to CLZ and RBIT+CLZ,
> respectively, instead of using gcc's builtin semi-defined variants?
Using inline asm instead has the drawback that it leaves a little less
opportunity for the compiler to
