Re: LLVM 22

On Thu, Jan 29, 2026 at 2:27 AM Andres Freund <andres@anarazel.de> 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).