Hi,
Good catch in noticing this.
On 2026-01-15 10:40:37 +0100, Anthonin Bonnefoy wrote:
> On Thu, Jan 15, 2026 at 4:20 AM Andreas Karlsson <andreas@proxel.se> wrote:
> > If inline-always does not do anything it should be removed on older LLVM
> > versions too. I do not think we should be having pre- and post-LLVM 17
> > run different passes. But as Thomas pointed out inline-always is likely
> > used for tuple deforming.
>
> Right, I've missed the l_callsite_alwaysinline for varsize_any.
> Testing with the following query to trigger a call to varsize_any:
>
> create table test_always_inline(id integer, data text);
> select data, id FROM test_always_inline;
>
> The generated bc were identical (attached with the message), with and
> without always-inline with varsize_any not being inlined. I think this
> is the same issue as with external functions. varsize_any is defined
> in postgres/access/common/heaptuple.bc, and the function needs to be
> imported for LLVM to be able to inline it. Without going through
> llvm_inline and importing the functions, there's no inlining doable.
Right - but the heuristic inline pass might *still* not inline even after
llvm_inline...
> Maybe the issue is that always-inline functions should be inlined,
> even with the non-optimized case (at least, that's what the configured
> passes seem to imply)? But that would require calling llvm_inline,
> which kind of defeats the purpose of having a dedicated PGJIT_INLINE
> flag and threshold.
No, it doesn't. E.g. the generated deform function should be inlined even if
we don't do the more expansive inlining.
> I've updated the patch with the simplified PGJIT_INLINE check and the
> commit message change. I've added a separate patch to remove the
> always-inline pass pre-LLVM 17 if we want to go that way.
I'm strongly against removing the always inline pass, I see absolutely no
reason for doing that. The whole point of always inline is that it happens
unconditionally. It's not an expensive pass either.
Greetings,
Andres Freund
