Re: LLVM 22

From: Anthonin Bonnefoy <anthonin(dot)bonnefoy(at)datadoghq(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Matheus Alcantara <matheusssilv97(at)gmail(dot)com>
Subject: Re: LLVM 22
Date: 2026-02-12 10:56:49
Message-ID: CAO6_Xqo6gUbLPxwdBWw4aHi1==wVbxcXNMdzzHKBb1seRz001A@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Attachment Content-Type Size
initial_jit_dump.ll application/octet-stream 5.0 KB
llvm_21_with_poison.ll application/octet-stream 1.8 KB
llvm_21_with_lifetime.ll application/octet-stream 1.8 KB

In response to

  • Re: LLVM 22 at 2026-01-29 01:27:29 from Andres Freund

Browse pgsql-hackers by date

  From Date Subject
Next Message Aya Iwata (Fujitsu) 2026-02-12 10:57:23 RE: [WIP]Vertical Clustered Index (columnar store extension) - take2
Previous Message Jim Jones 2026-02-12 10:45:30 Re: Add CREATE SCHEMA ... LIKE support