_mp_alloc to long int

Hans Åberg haberg-1 at telia.com
Thu Sep 29 20:34:28 CEST 2022

[Resent due to crash of mailman.]

> On 29 Sep 2022, at 17:38, Torbjörn Granlund <tg at gmplib.org> wrote:
> Hans Åberg <haberg-1 at telia.com> writes:
> At least in C++, there may be no memory savings with smaller ints due
> to alignment requirements. In GCC 12 (MacOS 12),
> __STDCPP_DEFAULT_NEW_ALIGNMENT__ is 16, meaning that operator new will
> allocate multiples of 16 bytes.
> We have a pointer, two size integers.
> On a 64-bit machine, these will currently be 8+4+4 = 16 bytes.

Right, I overlooked this. You would have to merge the two sizes into one.

> Now, let's not interpret __STDCPP_DEFAULT_NEW_ALIGNMENT__ as if every
> mpz_t is forced into that aligment.  Most of these are put on the stack,
> and should just get 8-byte aligned (even if, which I think is true, the
> stack pointer is 16-byte aligned at function entry).

This is a good point.

In C++, if changing sizes to size_t, both std::atomic_ref<A>::required_alignment and alignof(A) are 8. But for the type B, which corresponds to __mpz_struct, std::atomic_ref<B>::required_alignment = 16 and alignof(B)  8.

struct A {
  size_t a;
  size_t b;
  size_t* p;

std::atomic_ref<A>::required_alignment: 8
alignof(A): 8

struct B {
  int a;
  int b;
  size_t* p;

std::atomic_ref<B>::required_alignment: 16
alignof(B): 8

More information about the gmp-discuss mailing list