Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Tue, 06 Jan 2026 15:35:06 -0300
Message-Id: <DFHQ1F6JCNU8.SU1JOTEICGO2@gmail.com>
Cc: "PostgreSQL Hackers" <pgsql-hackers@lists.postgresql.org>
Subject: Re: LLVM 22
From: "Matheus Alcantara" <matheusssilv97@gmail.com>
To: "Thomas Munro" <thomas.munro@gmail.com>, "Matheus Alcantara"
 <matheusssilv97@gmail.com>
References: <CA+hUKGJTumad75o8Zao-LFseEbt=enbUFCM7LZVV=c8yg2i7dg@mail.gmail.com> <DFGZOTVPL100.Y09R8ROIHHTW@gmail.com> <CA+hUKGLNXakunn_FRe2ouy3G_5W-7sTCj2bz_ES1H=jhoHGsKQ@mail.gmail.com>
In-Reply-To: <CA+hUKGLNXakunn_FRe2ouy3G_5W-7sTCj2bz_ES1H=jhoHGsKQ@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/DFHQ1F6JCNU8.SU1JOTEICGO2%40gmail.com>
Precedence: bulk

On Mon Jan 5, 2026 at 8:50 PM -03, Thomas Munro wrote:
>> > Here's a potential minimal fix.  I haven't yet proven that the
>> > optimisation is still working as expected.  Probably need to compile
>> > an expression that calls an inlined function and then a non-inlined
>> > function with jit_dump_bitcode=3Dtrue, then find the right XXX.bc file
>> > under pgdata, llvm-dis XXX.bc, llc XXX.ll, then visually inspect XXX.s
>> > with enough caffeine to confirm that it's not spilling something (ie
>> > store instructions) where previously it didn't, but I wanted to post
>> > what I had so far to see if anyone has a better idea or an easy way to
>> > test it...
>> >
>> I'm not super familiar with reading assembly code but I tried my best to
>> inspect the LLVM 22 and LLVM 21 outputs and if I understood correctly I
>> think that 0002 is working as expected.
>
> Cool.  And as another sanity test, if you comment out the new poison
> code so that we don't try to prevent unwanted spills/stores, can you
> see any?
>
Yes, I've commented the poison code block introduced on 0002 and the
generated assembly code seems more bloated, for example:

LLVM 22 with 0002 and the poison code block commented:
    LBB2_8:
        mov	x25, #15624                     ; =3D0x3d08
        movk	x25, #7427, lsl #16
        movk	x25, #1, lsl #32
        mov	x20, #13805                     ; =3D0x35ed
        movk	x20, #7427, lsl #16
        movk	x20, #1, lsl #32
        ldr	x8, [x23]
        ldrb	w9, [x24]
        stur	x8, [x25, #-248]
        sturb	w9, [x25, #-240]
        mov	w26, #1                         ; =3D0x1
        strb	w26, [x20, #1419]
        ldurb	w8, [x25, #-240]
        cmp	w8, #1
        b.eq	LBB2_11

LLVM 22 with 0002:
    LBB2_8:
        mov	x20, #40824                     ; =3D0x9f78
        movk	x20, #19456, lsl #16
        movk	x20, #1, lsl #32
        ldr	x8, [x23]
        ldrb	w9, [x24]
        str	x8, [x20, #152]
        strb	w9, [x20, #160]
        mov	w26, #1                         ; =3D0x1
        strb	w26, [x20]
        cmp	w9, #1
        b.eq	LBB2_11

IIUC with the commented code the LLVM compiler added an extra
load ldurb followed by cmp w8, #1. With the patch it performs a
comparison cmp w9, #1 directly using a register it already has.

--
Matheus Alcantara
EDB: https://www.enterprisedb.com