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. 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. 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.
always_inline.s
Description: Binary data
v2-0002-Remove-always-inline-pass-for-LLVM-17.patch
Description: Binary data
v2-0001-Add-missing-JIT-inline-pass-for-llvm-17.patch
Description: Binary data
