public inbox for [email protected]
help / color / mirror / Atom feedFrom: Anthonin Bonnefoy <[email protected]>
To: Andres Freund <[email protected]>
Cc: Thomas Munro <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Cc: Matheus Alcantara <[email protected]>
Subject: Re: LLVM 22
Date: Thu, 12 Feb 2026 11:56:49 +0100
Message-ID: <CAO6_Xqo6gUbLPxwdBWw4aHi1==wVbxcXNMdzzHKBb1seRz001A@mail.gmail.com> (raw)
In-Reply-To: <5lusocererqcl4assiz6fbwvspjx422grxttzy46bnwicc3vwq@tzj22ll2daaw>
References: <CA+hUKGJTumad75o8Zao-LFseEbt=enbUFCM7LZVV=c8yg2i7dg@mail.gmail.com>
<CA+hUKGJv+QUOy8yOHe_0VfRGTSrHaCvo0xZG-1JGTqBurcPkOw@mail.gmail.com>
<CA+hUKGLJ63fpt_u0OXDR91fbpicDXK01fivzDSBMOtPazEanFQ@mail.gmail.com>
<CAO6_XqoH-6HBmrFZrRXQuc+_PvkMYDxXcbLW+fsUfTnUnMi2mA@mail.gmail.com>
<5lusocererqcl4assiz6fbwvspjx422grxttzy46bnwicc3vwq@tzj22ll2daaw>
On Thu, Jan 29, 2026 at 2:27 AM Andres Freund <[email protected]> wrote:
> The goal of the lifetime annotations was to allow llvm to remove stores an
> loads of FunctionCallInfo->{args,isnull}. After we stored e.g. fcinfo->isnull
> before a function call and then checked it after the function call, we don't
> need it anymore. I think that can only matter when the called function is
> actually inlined, otherwise there's no way that LLVM can see the store is
> unnecessary.
Thanks for the context, that makes things easier to understand.
I've run another test using:
- "select pg_last_xact_replay_timestamp();" for the query, compared to
int4mod, has a reachable PG_RETURN_NULL.
- run with "options='-cjit_inline_above_cost=0
-cjit_optimize_above_cost=100000 -cjit_above_cost=0
-cjit_dump_bitcode=true'" to force inlining while only going through
O0 pass.
- Then manually ran the optimisation pass with "opt-21
jit_initial_dump.ll --passes='default<O3>' -S"
The initial dump is using lifetime.end, but it can be used to check
what happens with poisoned values by manually replacing it.
Using lifetime_end, the store to isnull:
28:
store i8 1, ptr inttoptr (i64 200635374787156 to ptr), align 4
br label %pg_last_xact_replay_timestamp.exit
is indeed removed.
Removing the lifetime_end calls, the store call is still present (I
wanted to make sure it wasn't removed by another optimization)
Replacing the lifetime_end calls with poison stores generates the same
IR as if there was no lifetime_end, and the store call is still
present. Tested with opt-21 and opt-22.
So it looks like that using poison value doesn't replicate
lifetime_end behaviour (at least, for the jit dump I've tested).
Attachments:
[application/octet-stream] initial_jit_dump.ll (5.0K, 2-initial_jit_dump.ll)
download
[application/octet-stream] llvm_21_with_poison.ll (1.8K, 3-llvm_21_with_poison.ll)
download
[application/octet-stream] llvm_21_with_lifetime.ll (1.8K, 4-llvm_21_with_lifetime.ll)
download
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]
Subject: Re: LLVM 22
In-Reply-To: <CAO6_Xqo6gUbLPxwdBWw4aHi1==wVbxcXNMdzzHKBb1seRz001A@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