Re: LLVM 22 - Mailing list pgsql-hackers

From Andres Freund
Subject Re: LLVM 22
Date
Msg-id zv7wuadyqnxkl4tqlwzvrwghntn4ntgx4tn7s6cjyn354qp56e@wvf3yyibmpc6
Whole thread
In response to Re: LLVM 22  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: LLVM 22
List 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



pgsql-hackers by date:

Previous
From: "Jelte Fennema-Nio"
Date:
Subject: Re: Safer hash table initialization macro
Next
From: Melanie Plageman
Date:
Subject: Re: AIO / read stream heuristics adjustments for index prefetching