Re: llvmjit - improve code generated in O0

From: Pierre Ducroquet <p(dot)psql(at)pinaraf(dot)info>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: llvmjit - improve code generated in O0
Date: 2026-02-11 08:08:51
Message-ID: 0GPoJIzzLeRisSgUt4XECx1eV0cc_3IHcMhpMUObPxnWPQaZqSxyt6WaTFXD14W5XH5EdOG61NHSH6uJxXXbE2Oj6kUSv-PN_vqen5ALo74=@pinaraf.info
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Le mardi 10 février 2026 à 9:43 PM, Andres Freund <andres(at)anarazel(dot)de> a écrit :

> Hi,
>
> On 2026-02-10 17:39:40 +0000, Pierre Ducroquet wrote:
> > After spending some time looking at the assembly code generated by llvmjit
> > for a simple query (SELECT * FROM demo WHERE a = 42), digging in the IR
> > showed that by simply tweaking the IR one could push llvm into generating
> > better code, kind of "for free", without having to spend time in the LLVM
> > optimizer.
>
> Yea, if that's simple enough to do, there's no reason to not do that.
>
> I do think we eventually need a somewhat better "cheap" optimization
> pipeline. But even if we had that, there's no reason to not just immediately
> generate better code if it's cheap.
>
> Do these changes still make a difference after adding simplifycfg as you propose?

Nop, simplifycfg does all that so it makes these changes useless, and it is better at doing that than what I managed to do. But I've not looked at the impact on simplifycfg runtime, having less work to do may make it a tiny bit faster, and I also still have some edge cases I want to try regarding the impact of simplifycfg.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Etsuro Fujita 2026-02-11 08:14:36 Re: Instability in postgres_fdw regression tests
Previous Message John Naylor 2026-02-11 07:10:37 Re: refactor architecture-specific popcount code