public inbox for [email protected]
help / color / mirror / Atom feedFrom: Thomas Munro <[email protected]>
To: Andres Freund <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: Devrim Gündüz <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Cc: Matheus Alcantara <[email protected]>
Cc: Anthonin Bonnefoy <[email protected]>
Subject: Re: LLVM 22
Date: Fri, 3 Apr 2026 16:04:13 +1300
Message-ID: <CA+hUKG+skVJgFiqjxGo1E72rMULqSRs09PJc9sWKySpCvN8RKA@mail.gmail.com> (raw)
In-Reply-To: <zv7wuadyqnxkl4tqlwzvrwghntn4ntgx4tn7s6cjyn354qp56e@wvf3yyibmpc6>
References: <CA+hUKGJTumad75o8Zao-LFseEbt=enbUFCM7LZVV=c8yg2i7dg@mail.gmail.com>
<CA+hUKGJv+QUOy8yOHe_0VfRGTSrHaCvo0xZG-1JGTqBurcPkOw@mail.gmail.com>
<CA+hUKGLJ63fpt_u0OXDR91fbpicDXK01fivzDSBMOtPazEanFQ@mail.gmail.com>
<[email protected]>
<[email protected]>
<CA+hUKGL1LfD7BTACTx=E78gq_jiFU727osd6tHCnbERrqY8DOA@mail.gmail.com>
<CA+hUKGJFVyQA8QOjB3BSuq9N1VbTvMPzsFG93p=4TmLR8R58zA@mail.gmail.com>
<zv7wuadyqnxkl4tqlwzvrwghntn4ntgx4tn7s6cjyn354qp56e@wvf3yyibmpc6>
On Fri, Apr 3, 2026 at 3:31 AM Andres Freund <[email protected]> wrote:
> > 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.
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 fair
> 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.
view thread (15+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: LLVM 22
In-Reply-To: <CA+hUKG+skVJgFiqjxGo1E72rMULqSRs09PJc9sWKySpCvN8RKA@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox