Re: LLVM 22

Andres Freund <andres@anarazel.de>

From: Andres Freund <andres@anarazel.de>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Devrim Gündüz <devrim@gunduz.org>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Matheus Alcantara <matheusssilv97@gmail.com>, Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com>
Date: 2026-04-02T14:31:48Z
Lists: pgsql-hackers
Hi,

On 2026-04-02 16:20:41 +1300, Thomas Munro wrote:
> On Wed, Apr 1, 2026 at 4:25 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> > Working on this, more shortly...  I'm trying to figure out if Anthonin
> > and Andres's feedback means the poison approach does nothing useful
> > and we might as well just #ifdef out the lifetime.end stuff for LLVM
> > >= 22 to fix the breakage today.
> 
> Done.  Hopefully midge and Devrim will now turn green :-)

Thanks!


> > Either way it looks like we need a patch to use alloca instead, which
> > I'll also look into...
> 
> I see a few options, but I need to hack on them for a while to figure
> out the tradeoffs, or what I'm missing...  after the freeze.

I've experimented a bunch with this, it seems we need the larger changes done
as part of the patchset for removing pointers from the expressions to actually
allow recent-ish LLVM to optimize this.  I did verify that what we did didn't
have an effect with any other recent LLVM either.

The real fix here might be to have a separate calling convention for the very
common case of a scalar stable function with 1-3 arguments.  We loose a fair
bit of efficiency even in interpreted execution due to ferrying arguments,
their nullness, and the nullness of the return value through memory.

Greetings,

Andres Freund



Commits

  1. jit: No backport::SectionMemoryManager for LLVM 22.

  2. jit: Stop emitting lifetime.end for LLVM 22.