Re: Add missing JIT inline pass for llvm>=17

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Anthonin Bonnefoy <anthonin(dot)bonnefoy(at)datadoghq(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Add missing JIT inline pass for llvm>=17
Date: 2026-01-15 02:33:13
Message-ID: CA+hUKGLF1T+fgASQrVbDw2jdpt1d1ks7Lcs1rrhZMa+eXSQb6g@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jan 14, 2026 at 9:02 PM Anthonin Bonnefoy
<anthonin(dot)bonnefoy(at)datadoghq(dot)com> wrote:
> The attached patch adds the inline pass when jit inlining is triggered
> without optimisation, as was done with LLVM<17.

Oof, right. Commit message should mention that this was an oversight
in 76200e5e. I think we should back-patch this.

if (context->base.flags & PGJIT_OPT3)
passes = "default<O3>";
+ else if (context->base.flags & PGJIT_INLINE
+ && !(context->base.flags & PGJIT_OPT3))
+ /* if doing inlining, but no expensive optimization, add inline pass */
+ passes = "default<O0>,mem2reg,inline";
else
passes = "default<O0>,mem2reg";

That expression after && is redundant with the "else".

> I didn't add the always-inline pass as I don't think this can have any
> effect. From what I understand, the functions need to be imported
> through llvm_inline for LLVM to be able to inline them. I've tested by
> tagging int4mod as always inline, and the generated bc was still
> calling the function despite the always-inline pass.

What about llvmjit_deform.c's use of l_callsite_alwaysinline()?

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andreas Karlsson 2026-01-15 03:20:45 Re: Add missing JIT inline pass for llvm>=17
Previous Message Noah Misch 2026-01-15 02:20:35 Re: Updating IPC::Run in CI?