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