On Fri, 10 Jul 2026, Kyrylo Tkachov wrote: > > > > On 10 Jul 2026, at 18:33, Jeffrey Law <[email protected]> wrote: > > > > > > > > On 7/10/2026 10:01 AM, Kyrylo Tkachov wrote: > >> > >>> On 10 Jul 2026, at 16:18, Alfie Richards <[email protected]> wrote: > >>> > >>> On 10/07/2026 15:09, Kyrylo Tkachov wrote: > >>>>> 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) > >>>> Thanks for this. Can you also share the options used? > >>>> Kyrill > >>> I believe they are: > >>> > >>> -mcpu=native -Ofast -fomit-frame-pointer -flto=auto --param > >>> ipa-cp-eval-threshold=1 --param ipa-cp-unit-growth=80 > >> Ok, I think the key option here is -fno-strict-aliasing and the reduced > >> test case would be: > >> https://godbolt.org/z/x8dP1P75e > >> -fsplit-paths legitimately removes a pointer-chasing load outside the hot > >> loop (the x4 load).
I think people shouldn't need to use -fno-strict-aliasing on libquantum? (not that SPEC 2006 is relevant these days) > >> Any opinions from others on how to approach this? Shall I file this case > >> as a missed-optimization PR so we can discuss how else we may handle this > >> case? Or we can reinstate -fsplit-paths as off-by-default and tell people > >> who want libquantum performance to use -fsplit-paths explicitly in their > >> options? > > Definitely open a bug with the testcase. We'll dive in and try to draw > > some conclusions. > > Opened PR126208. > Thanks, > Kyrill > > > > > jeff > > > -- Richard Biener <[email protected]> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Jochen Jaser, Andrew McDonald; (HRB 36809, AG Nuernberg)
