On 10 Jul 2026, at 15:57, Alfie Richards <[email protected]> wrote:
On 10/07/2026 11:42, Kyrylo Tkachov wrote:
On 9 Jul 2026, at 14:36, Kyrylo Tkachov <[email protected]> wrote:
Hi Alfie,
On 9 Jul 2026, at 10:24, Alfie Richards <[email protected]> wrote:
On 06/07/2026 09:40, Kyrylo Tkachov wrote:
On 3 Jul 2026, at 13:56, Kyrylo Tkachov <[email protected]> wrote:
On 2 Jul 2026, at 10:56, Richard Biener <[email protected]> wrote:
On Thu, 2 Jul 2026, [email protected] wrote:
From: Kyrylo Tkachov <[email protected]>
pass_split_paths duplicates the join block of an IF-THEN-ELSE that feeds a
loop latch, splitting the two paths to the backedge. It runs only at -O3.
In practice it interacts badly with later optimizations: it duplicates the
loop body before loads have been commoned and before if-conversion runs, so
it can block both loop unrolling (PR120892) and if-conversion of the
duplicated diamond, while its own heuristic already declines about half of
all candidate blocks, most often to avoid spoiling if-conversion.
Remove the pass and deprecate the -fsplit-paths option. The option is kept
accepted for backward compatibility via the Ignore flag and now does nothing,
matching how other optimization options have been retired (for example
-ftree-lrs). param_max_jump_thread_duplication_stmts is retained as it is
shared with the jump-threading passes.
Statistics from the pass on SPEC CPU 2026 (intrate + fprate, counted from the
split-paths dump):
candidates splits declined to protect if-conversion
-O3 122894 62050 60844 37166
-O3 -flto=auto 52423 21257 31166 21822
The pass splits about half of the blocks it considers and declines the rest,
most often to avoid spoiling if-conversion. The duplication grows .text by
0.32% at -O3 and 0.24% at -O3 -flto=auto.
Andrea and Jeff indicated in PR120892 that removing -fsplit-paths may be
the way to go there.
-fsplit-paths also complicates the control-flow and defeats the
load-commoning necessary to get good if-conversion of the hot loop from
Snappy from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125557#c13 .
Bootstrapped and tested on aarch64-none-linux-gnu and x86_64-linux.
OK.
Please leave others a day or so to chime in.
Thanks, I’ll push next wee once the USA have had their holidays.
Kyrill
Pushed now as g:5c23bb074af23f00dd3fe1745b9dd99245fa4bba
Hi,
Just to note we see about a 3% regression on spec2006.intrate.462.libquantum
from this change on Neoverse-V1.
I’m having a look. I don’t have access to a Neoverse V1 but I’ll try to
reproduce it on the machines that I have access to and see if I can raise a GCC
PR to record whatever missed optimisation this may be exposing so that we can
decide if we want to implement it in some other way.
So I did reproduce the slowdown, but it looks like an unfortunate code
alignment change. libquantum has some very hot paths but the split paths pass
only triggered on cold paths/functions, but due to code layout the hot BBs got
a different suboptimal alignment that caused the overall slowdown. So I don’t
think we have anything split-paths-related to do here.
Alignment for big AArch64 CPUs is something that has given me headaches
recently and I think we should be looking at things like stricter alignment on
small hot loops and better function alignment for hot functions (ignoring skip
in those cases), but those are separate discussions.
Thanks,
Kyrill
Hi Kyrill,
Our analysis showed a larger code generation difference.
Speicifcally in quantum_toffoli near the end of the loop we see the following
change:
NEW:
//.L1
cmp w2, w1
b.le 404a40 <quantum_toffoli+0x174> // Out of loop
//.L2
ldr x0, [x19, #16]
add x0, x0, w1, uxtw #4
add x1, x1, #0x1
ldr x3, [x0, #8]
bics xzr, x5, x3
b.ne 404a0c <quantum_toffoli+0x140> // b.any // .L1
//.L3
eor x3, x4, x3
str x3, [x0, #8]
ldr w2, [x19, #4]
cmp w2, w1 b.gt 404a14 <quantum_toffoli+0x148> // .L2
OLD:
//.L1
add x3, x5, w0, uxtw #4
ldr x1, [x3, #8]
bics xzr, x19, x1
b.eq 404a9c <quantum_toffoli+0x17c> // b.none // Out of loop
//.L2
add x0, x0, #0x1
cmp w2, w0
b.gt 404a68 <quantum_toffoli+0x148> // .L1
(Roughly, comments are my own)
We think this is the primary change causing this regression due to the extra
load in the loop?
(credit to Tamar for most of the analysis here)
