| 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.
| 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 |