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

On Tue, Jan 6, 2026 at 10:56=E2=80=AFAM Matheus Alcantara
<matheusssilv97@gmail.com> wrote:
> On Fri Jan 2, 2026 at 11:02 PM -03, Thomas Munro wrote:
> > Intrinsic has incorrect argument type!
> > ptr @llvm.lifetime.end.p0
> > Intrinsic has incorrect argument type!
> > ptr @llvm.lifetime.end.p0
> > 2026-01-02 17:28:31.394 NZDT client backend[42798] pg_regress/boolean
> > FATAL:  fatal llvm error: Broken module found, compilation aborted!
> >
> I've managed to reproduce this using LLVM 22.

Thanks for testing!

> > 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?

> I've noticed a reduction on some instructions when using LLVM 22 with
> the 0002 patch compared with LLVM 21. For example, here we needed less
> instructions to set up the registers:
>
> LLVM 22:
>     LBB2_8:                                 ; %b.op.1.start
>         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]
>
> LLVM 21:
>     LBB2_8:                                 ; %b.op.1.start
>         mov     x25, #25352                     ; =3D0x6308
>         movk    x25, #2946, lsl #16
>         movk    x25, #1, lsl #32
>         mov     x20, #23533                     ; =3D0x5bed
>         movk    x20, #2946, lsl #16
>         movk    x20, #1, lsl #32
>         ldr     x8, [x23]
>         ldrb    w9, [x24]
>         stur    x8, [x25, #-248]
>         sturb   w9, [x25, #-240]
>
> I've also noticed that the generated assembly code for LLVM 22 use the
> str and strb instructions instead of stur and sturb in some cases, which
> according to IA is an improvement but unfortunately I did not find any
> reference to prove this, sorry.

Interesting.