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).
initial_jit_dump.ll
Description: Binary data
llvm_21_with_poison.ll
Description: Binary data
llvm_21_with_lifetime.ll
Description: Binary data
