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 <[email protected]> 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
