Richard Biener <rguent...@suse.de> 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. -- Torbjörn Please encrypt, key id 0xC8601622 _______________________________________________ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel
