On Mon, Aug 24, 2026 at 12:25 PM Aldy Hernandez <[email protected]> wrote: > > On Mon, Aug 24, 2026 at 11:17:09AM -0600, Jeffrey Law wrote: > > > > > > On 8/24/2026 7:03 AM, Aldy Hernandez wrote: > > > [Richi, per your suggestion...is this what you had in mind?] > > > > > > DOM's jump threader duplicates a join block that merges comparisons > > > into a boolean that is immediately tested: > > > > > > <bb 3>: > > > t_9 = a < b; > > > goto <bb 5>; > > > > > > <bb 4>: > > > t_6 = c < d; > > > goto <bb 5>; > > > > > > <bb 5>: > > > # t_1 = PHI <t_9(3), t_6(4)> > > > if (t_1 != 0) > > Jeez. More stuff I don't remember adding. Presumably the goal here is to > > duplicate the test from bb5 into bb3 and change it to test a < b and a > > similar transformation in bb4 testing c < d which likely happens after DOM > > was run. It probably opens up potential threading opportunities as well. > > You can't remember cause it wasn't you ;-): > > commit 1d53751dd563d30e4400e4a2da530d8ea07da44b > Author: Jiufu Guo <[email protected]> > Date: Thu Jun 13 18:55:55 2019 +0000 > > re PR tree-optimization/77820 (A jump threading opportunity with > conditionals) >
Looking into the history of at least PR 37537 (which is marked as a dup of PR 77820); this originally showed up in spec cpu 2000's facerec benchmark. Though it seems like the gfortran front-end was changed to prevent creating this (by Jakub). Though I don't know where Segher got the idea for PR 77820; (see below link where he mentioned SPEC CPU 2006 or so; but I think it was the same thing I had looked at earlier). So it was originally posted as its own pass even: https://gcc.gnu.org/pipermail/gcc-patches/2019-May/521049.html > > > > > > > > > > > Implement this optimization in the phiopt pass, without using the jump > > > threading machinery DOM's version uses. This was an optimization we > > > lost with the jump threader rewrite, which DOM ended up picking up. > > Given the compile-time cost of DOM vs phiopt and the fact that we run phiopt > > repeatedly through the pipeline, this seems like a very sensible thing to > > do. > > > > > > Measured over GCC's own sources plus LAPACK, the phiopt version takes > > > over ~94% of the joins DOM's special case caught: DOM registrations > > > for this optimization drop from 3536 to 196, with 1325 phiopt > > > replications; the remainder are cases that show up between phiopt and > > > DOM. Optimizations at loop boundaries (approx 700) are deliberately > > > left to the DOM threader, as replicating those would change loop > > > structure. I could loosen this restriction, but I've learned to fear > > > all things loop ;-). > > > > > > I've left DOM's version in place, just in case we still want to allow > > > it for loop things, but I can just as easily drop it in a follow-up > > > patch. > > If the goal is to remove DOM or at least significantly neuter it, then we > > probably want to loosen the restriction in phiopt, though given my lack of > > memory of this code I couldn't even start to suggest what heuristics we > > might want or if there were meaningful testcases which drove the desire for > > this optimization. > > OK, I'll leave the restriction until I'm told otherwise. > > > > > > > > > > > Tested on ppc64le Linux. > > > > > > OK? > > > > > > PR tree-optimization/126896 > > > > > > gcc/ChangeLog: > > > > > > * tree-ssa-phiopt.cc: Include tree-ssa-threadedge.h. > > > (preserves_loop_structure_p): New. > > > (replicate_cond_into_pred): New. > > > (replicate_conds_over_phis): New. > > > (pass_phiopt::execute): Call replicate_conds_over_phis. > > > > > > gcc/testsuite/ChangeLog: > > > > > > * gcc.dg/tree-ssa/phi_on_compare-1.c: Scan the phiopt2 dump. > > > * gcc.dg/tree-ssa/phi_on_compare-2.c: Scan the optimized dump. > > > * gcc.dg/tree-ssa/phi_on_compare-3.c: Likewise. > > > * gcc.dg/tree-ssa/dom-jump-threading-1.c: Disable phiopt. > > > * gcc.dg/tree-ssa/dom-jump-threading-2.c: Likewise. > > > * gcc.dg/tree-ssa/phi_on_compare-5.c: New test. > > So just one question, why is this gated on !early? Everything looks > > sensible to me. > > It was nothing as fancy as Andrea's answer :). It was merely to keep > the optimization close in the pipeline as to where DOM was doing it. > Phiopt with early_p=true runs way before the first DOM does, and it > seems before IPA, so I thought the safe thing to do was to run it from > early_p=false on. I can add a comment in the code to that effect if > you'd like. > > OK? > > Thanks. > Aldy
