GMP 6 the incomatible GMP?

Richard Biener rguenther at
Tue Jan 8 11:26:19 CET 2013

On Tue, 8 Jan 2013, Torbjorn Granlund wrote:

> nisse at (Niels M?ller) writes:
>   Hmm. I guess one could go down to only 8 bits or so for the alloc field,
>   and for larger allocations, store the number of allocated limbs at the
>   head of the limb array (in the case limb size is not artificially small,
>   it could be just _mp_d[-1]).
> That's another idea.
>   Do you think 48 bits (or 47 bits absolute value) for _mp_size will be
>   large enough for the foreseeable future (say, 10 years)?
> I think that will be sufficient for some hundred years, since any
> super-linear algorithm applied to an operand of 2^53 bits (2^47 64-bit
> limbs) would hardly ever terminate even with a multi-THz CPU.
>   There are also other tweaks discussed for mpz_t, to allow initialization
>   without allocation.
> Yep, we should do that too.  I cannot recall the details, but I assume
> that this would not create an incompatibility?

Another idea is to embed limbs for small numbers into __mpz_struct itself
(I was playing with that idea to reduce the number of allocations done
by ISL used by GCC now).  Sort of have a magic _mp_alloc number (zero?)
that tells GMP that everything after _mp_alloc are the actual limbs.
Thus have

typedef struct
  int _mp_alloc;
  int _mp_size;
  union {
    mp_libm_t *_mp_d;
    mp_libm_t embed_limbs[N];
} __mpz_struct;

with suitable N (what's a suitable number of limbs to special-case,
given that limb-size is target dependent?  One limb would be easiest
(just use the space of the _mp_d pointer), extra "half" limbs would be
ugly I suppose.

ISL has lots of arrays of __mpz_structs which seem to be often
copied around and the actual numbers are usually small (would fit
into 64bits).

Doing this wouldn't create an incompatibility I think, but if you
re-org things anyway maybe there is a better opportunity to
layout things.


Richard Biener <rguenther at>
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
GF: Jeff Hawn, Jennifer Guild, Felix Imend

More information about the gmp-devel mailing list