Re: pgsql: Optimize tuple deformation

On Fri, 9 Oct 2026 at 04:44, Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
>
> On 07.10.26 10:54, David Rowley wrote:
> > It was done to work around a problem with gcc where it was refusing to
> > index the CompactAttribute array by adding 8 to the previous address
> > to get the address of the next element. Instead, it was doing LEA on
> > each loop, which was slower due to shift and add rather than just add.
> > The best I could figure out is that gcc didn't want to optimise to use
> > LEA due to concerns about the integer wrapping around, which, if it
> > did, would be a different address than doing 2^31 adds on a 64-bit
> > pointer.
>
> Oh! :-/
>
> How about a really big comment about that, and maybe change the type
> from size_t to uint64 (or maybe uintptr_t, if it's supposed to vary on
> 32-bit platforms), so it looks more intentional and not like a mistake?

I don't object to having more details there. The problem was that I
just wasn't that certain why gcc was doing this. The above is just a
theory which might be incorrect. When I mock up trivial examples in
godbolt.org, I can't recreate the problem, so it may have something to
do with register pressure because there are so many things in flight
that there's a shortage of registers to store required values.

I'd like to get time to put in more effort into figuring out what's
going on with the gcc as I wondered how many other places we're
getting inefficient code because of this. More research may discover
that we really shouldn't use ints to index arrays, for example.

It is meant to be 32-bits on 32-bit platforms. Why is uintptr_t better
than size_t for indexing an array? Or rather, what's wrong with
size_t? I had assumed you highlighted this because of some fields
being int and some being size_t, but if you're happier with uintptr_t,
then I may have misunderstood.

David