speed of mpz_odd_p and lazy allocation

[Niels Möller]

Marc Glisse <marc.glisse at inria.fr> writes:

> a piece of code that always bothered me:
>
> /* Using "&" rather than "&&" means these can come out branch-free.  Every
>    mpz_t has at least one limb allocated, so fetching the low limb is always
>    allowed.  */
> #define mpz_odd_p(z)   (((z)->_mp_size != 0) & __GMP_CAST (int, (z)->_mp_d[0]))

> Is this branch in mpz_odd_p so bad, or can I move
> it back to '&&'? (I also want to tweak mpz_get_ui so _mp_d is not
> dereferenced when the size is 0)

Why do you want to do that change now? If you'd prefer to have GMP
never dereference mp_d when mp_size == 0, then I think we ought to
discuss that.

Off the top of my head, I think it would make some sense to do mpz_init
without allocation as

void mpz_init (mpz_t x)
{
  static const mp_limb_t zero = 0;
  x->_mp_d = &zero;
  x->_mp_alloc = x->_mp_size = 0;
}

I also have some related ideas, in particular to use _mp_alloc = 0 to
mean that storage was allocated by the application. Such an mpz_t should
be used only as input to gmp functions, never as output. One use would
be for compile time constant bignums.

Reards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.