MIME-Version: 1.0
References: 
 <CA+hUKGJTumad75o8Zao-LFseEbt=enbUFCM7LZVV=c8yg2i7dg@mail.gmail.com>
 <CA+hUKGJv+QUOy8yOHe_0VfRGTSrHaCvo0xZG-1JGTqBurcPkOw@mail.gmail.com>
 <CA+hUKGLJ63fpt_u0OXDR91fbpicDXK01fivzDSBMOtPazEanFQ@mail.gmail.com>
 <afa3914d40d592fc57f50da0d1e99d91f5c8b7dc.camel@gunduz.org>
 <2805479.1775001311@sss.pgh.pa.us>
 <CA+hUKGL1LfD7BTACTx=E78gq_jiFU727osd6tHCnbERrqY8DOA@mail.gmail.com>
 <CA+hUKGJFVyQA8QOjB3BSuq9N1VbTvMPzsFG93p=4TmLR8R58zA@mail.gmail.com>
 <zv7wuadyqnxkl4tqlwzvrwghntn4ntgx4tn7s6cjyn354qp56e@wvf3yyibmpc6>
In-Reply-To: <zv7wuadyqnxkl4tqlwzvrwghntn4ntgx4tn7s6cjyn354qp56e@wvf3yyibmpc6>
From: Thomas Munro <thomas.munro@gmail.com>
Date: Fri, 3 Apr 2026 16:04:13 +1300
Message-ID: 
 <CA+hUKG+skVJgFiqjxGo1E72rMULqSRs09PJc9sWKySpCvN8RKA@mail.gmail.com>
Subject: Re: LLVM 22
To: Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
 =?UTF-8?B?RGV2cmltIEfDvG5kw7x6?= <devrim@gunduz.org>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
	Matheus Alcantara <matheusssilv97@gmail.com>,
	Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CA%2BhUKG%2BskVJgFiqjxGo1E72rMULqSRs09PJc9sWKySpCvN8RKA%40mail.gmail.com>
Precedence: bulk

On Fri, Apr 3, 2026 at 3:31=E2=80=AFAM Andres Freund <andres@anarazel.de> w=
rote:
> > 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 act=
ually
> allow recent-ish LLVM to optimize this.  I did verify that what we did di=
dn't
> have an effect with any other recent LLVM either.

Yeah, I noticed this connection as well, coming at it from a keyhole
how-do-I-fix-THIS-problem angle.  It seemed to me that where
ExecInitFunc() builds the code to compute argument values to push into
&fcinfo->args[argno].value (a palloc'd FunctionCallInfoData object),
it might first alloca the space and store the collid etc (and after
return, it could lifetime.end it, or maybe the eventual ret in the
caller is enough but I don't see any reason not to lifetime.end it
ASAP), and then the destination would become a pointer into that, and
the most natural thing would be a stack pointer-relative one, and then
you'd have removed a major source of non-cacheability of compiled
expressions.  It took me a while to grok the function argument layout,
which is ... this might be a stretch... a bit like Fortran, neither a
linear stack nor a spaghetti stack, but just a bag of variables ready
to be used as functions arguments, with recursion not permitted.  And
also to grok the quirks of our V1 calls that compelled you to do it
like that.  But I'm still learning the secrets of this code and I may
be way off base in these musings, I haven't actually tried anything
and it sounds like I should keep out of your way...

> 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 f=
air
> bit of efficiency even in interpreted execution due to ferrying arguments=
,
> their nullness, and the nullness of the return value through memory.

Yeah.  I understand much better why you say that now.
FunctionCallInfoData holds data with two different lifetimes, some of
which might not be needed.