Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Thu, 22 Jan 2026 18:40:46 -0300
Message-Id: <DFVG0AV650GW.2CNS5CZ4OG788@gmail.com>
Cc: "pgsql-hackers@lists.postgresql.org"
 <pgsql-hackers@lists.postgresql.org>
Subject: Re: [PATCH] llvmjit: always add the simplifycfg pass
From: "Matheus Alcantara" <matheusssilv97@gmail.com>
To: "Pierre Ducroquet" <p.psql@pinaraf.info>
References: <VS3dpR1Sf5jGnWwoFFJ-_x3GbW7fdmV0arzWPIDfrmbVzewifgu6DsQ7oDa-TAwRz9N2p817j3jGstHwfPOJJxOipbcp-nHdNj3zyxKvC4Q=@pinaraf.info> <DFVDQRXJX7QW.KLYVOJSQW08Y@gmail.com> <H9LI9Enj4-NPP6t2g1RB9KMGkkBwzWjQwfiSLHLOTnT7YUwVPYSu_pMHwQLwwzGQGp54DQcER-eLngTa1GzVjH5Q0addrvfalukYnszTjMY=@pinaraf.info>
In-Reply-To: <H9LI9Enj4-NPP6t2g1RB9KMGkkBwzWjQwfiSLHLOTnT7YUwVPYSu_pMHwQLwwzGQGp54DQcER-eLngTa1GzVjH5Q0addrvfalukYnszTjMY=@pinaraf.info>
Archived-At: <https://www.postgresql.org/message-id/DFVG0AV650GW.2CNS5CZ4OG788%40gmail.com>
Precedence: bulk

On Thu Jan 22, 2026 at 5:27 PM -03, Pierre Ducroquet wrote:
>> The patch needs a rebase due to e5d99b4d9ef.
>>=20
>> You've added the "simplifycfg" only when the "jit_optimize_above_cost"
>> is not triggered which will use the default<O0> and mem2reg passes, the
>>=20
>> default<O3> pass already include "simplifycfg"?
>>=20
>>=20
>> With e5d99b4d9ef being committed, should we add "simplifycfg" when
>> PGJIT_INLINE bit is set since it also use the default<O0> and mem2reg
>>=20
>> passes?
>
> Hi
>
> Thank you, here is a rebased version of the patch.
> To answer your questions:
> - O3 already includes simplifycfg, so no need to modify O3
> - any code generated by our llvmjit provider, esp. tuple deforming, is he=
avily dependent on simplifycfg, so when O0 is the basis we should always ad=
d this pass

Thanks for confirming.

I did some benchmarks on some TPCH queries (1 and 4) and I got these
results. Note that for these tests I set jit_optimize_above_cost=3D1000000
so that it force to use the default<O0> pass with simplifycfg.

Master Q1:
    Timing: Generation 1.553 ms (Deform 0.573 ms), Inlining 0.052 ms, Optim=
ization 95.571 ms, Emission 58.941 ms, Total 156.116 ms
    Execution Time: 38221.318 ms

Patch Q1:
    Timing: Generation 1.477 ms (Deform 0.534 ms), Inlining 0.040 ms, Optim=
ization 95.364 ms, Emission 58.046 ms, Total 154.927 ms
    Execution Time: 38257.797 ms

Master Q4:
    Timing: Generation 0.836 ms (Deform 0.309 ms), Inlining 0.086 ms, Optim=
ization 5.098 ms, Emission 6.963 ms, Total 12.983 ms
    Execution Time: 19512.134 ms

Patch Q4:
    Timing: Generation 0.802 ms (Deform 0.294 ms), Inlining 0.090 ms, Optim=
ization 5.234 ms, Emission 6.521 ms, Total 12.648 ms
    Execution Time: 16051.483 ms


For Q4 I see a small increase on Optimization phase but we have a good
performance improvement on execution time. For Q1 the results are almost
the same.

I did not find any major regression using simplifycfg pass and I think
that it make sense to enable since it generate better IR code for LLVM
to compile without too much costs. +1 for this patch.

Perhaps we could merge the comments on if/else block to include the
simplifycfg, what do you think?

+       /*
+        * Determine the LLVM pass pipeline to use. For OPT3 we use the sta=
ndard
+        * suite. For lower optimization levels, we explicitly include mem2=
reg to
+        * promote stack variables, simplifycfg to clean up the control flo=
w , and
+        * optionally the inliner if the flag is set. Note that default<O0>=
 already
+        * includes the always-inline pass.
+        */
        if (context->base.flags & PGJIT_OPT3)
                passes =3D "default<O3>";
        else if (context->base.flags & PGJIT_INLINE)
-               /* if doing inlining, but no expensive optimization, add in=
line pass */
                passes =3D "default<O0>,mem2reg,simplifycfg,inline";
        else
-               /* default<O0> includes always-inline pass */
                passes =3D "default<O0>,mem2reg,simplifycfg";

--
Matheus Alcantara
EDB: https://www.enterprisedb.com