Re: llvmjit - improve code generated in O0 - Mailing list pgsql-hackers

From Pierre Ducroquet
Subject Re: llvmjit - improve code generated in O0
Date
Msg-id 0GPoJIzzLeRisSgUt4XECx1eV0cc_3IHcMhpMUObPxnWPQaZqSxyt6WaTFXD14W5XH5EdOG61NHSH6uJxXXbE2Oj6kUSv-PN_vqen5ALo74=@pinaraf.info
Whole thread
In response to Re: llvmjit - improve code generated in O0  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Le mardi 10 février 2026 à 9:43 PM, Andres Freund <andres@anarazel.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
Ialso still have some edge cases I want to try regarding the impact of simplifycfg. 



pgsql-hackers by date:

Previous
From: John Naylor
Date:
Subject: Re: refactor architecture-specific popcount code
Next
From: Etsuro Fujita
Date:
Subject: Re: Instability in postgres_fdw regression tests