Has there been historical work done to investigate small integer optimization?
Richard Biener
rguenther at suse.de
Mon Feb 12 13:01:45 CET 2024
On Mon, 12 Feb 2024, Richard Biener wrote:
> On Mon, 12 Feb 2024, Torbj?rn Granlund wrote:
>
> > marco.bodrato at tutanota.com writes:
> >
> > But implementing it with the current mpz type is "impossible".
> > I mean, one should break the current interface.
> > Currently, _mp_d is always a pointer AND it always point to a readable limb. Even if _mp_alloc is zero.
> >
> > If we set alloc = 0 and size >= 2^30, then that means the the pointer
> > field is actually a numeric value, and perhaps the low 30 bits of the
> > size field is more bits for the numeric value. :-)
>
> Since both _mp_alloc is signed _mp_alloc < 0 could indicate an inline
> limb, you can then declare _mp_size irrelevant, fixed to one limb
> plus 2 * sizeof (int) * 8 - 1 bits. Though that missing bit is
> likely going to be awkward (also the position of the sign-bit given
> endianesses).
Oh, and _mp_alloc < 0 could also simply mean the allocation is
"inline", aka
typedef struct
{
int _mp_alloc; /* Number of *limbs* allocated and pointed
to by the _mp_d field. */
int _mp_size; /* abs(_mp_size) is the number of limbs
the
last field points to. If _mp_size is
negative this is a negative number. */
union {
mp_limb_t *_mp_d; /* Pointer to the limbs. */
mp_limb_t _mp_inline_limbs[]; /* Inline limbs if _mp_alloc < 0. */
};
} __mpz_struct;
you could then no longer pass such __mpz_struct by value though but
it would allow on-stack allocations of (small) temporary __mpz_struct
using alloca.
Richard.
More information about the gmp-devel
mailing list