How large are arbitrarily large integers? (Was Re: Bitfield subtlety)

Torbjörn Granlund tg at
Thu Mar 29 08:43:28 UTC 2018

Richard Biener <rguenther at> writes:

  You can also steal low-order bits from the pointer depending on
  alignment...  and depending on the host also some high-order bits.

I will resist those temptations.  :-)

(I have contemplates using the 2-3 low point bits for some other
purposes, most likely to track used allocators.  But I don't think that
will happen.)

  You can also simply off-load the allocation size to the allocated
  area (like to *(size_t)(_mp_d - 8)).  In fact you are already breaking
  the ABI in some sort by re-purposing fields given that the internals
  of __mpz_struct is exposed.

Unfortunately, while that would be desirable, I have the feeling that it
is not 100% portable.

  Not sure if you are already doing small-numbers optimization like
  avoiding any allocation for size == 1 by re-purposing _mp_d as
  the single allocated limb (where the size of _mp_d makes this possible).

We don't do that, no.

  2TiB is not unheard of - but my immediate followup question would be
  why the storage needs to be in RAM?  Why can't mpz operate on offline
  storage like large SSDs?

Too poor memory locality of the current large operand multiply.

Please encrypt, key id 0xC8601622

More information about the gmp-devel mailing list