On Fri, Sep 10, 2021 at 6:32 PM Jeff Law via Gcc-patches < gcc-patches@gcc.gnu.org> wrote:
> > > On 9/10/2021 7:53 AM, Aldy Hernandez via Gcc-patches wrote: > > > > > > On 9/10/21 3:16 PM, Michael Matz wrote: > >> Hi, > >> > >> On Fri, 10 Sep 2021, Aldy Hernandez via Gcc-patches wrote: > >> > >>> } > >>> + > >>> + /* Threading through a non-empty latch would cause code to be added > >> > >> "through an *empty* latch". The test in code is correct, though. > > > > Whoops. > > > >> > >> And for the before/after loops flag you added: we have a > >> cfun->curr_properties field which can be used. We even already have a > >> PROP_loops flag but that is set throughout compilation from CFG > >> construction until the RTL loop optimizers, so can't be re-used for what > >> is needed here. But you still could invent another PROP_ value > >> instead of > >> adding a new field in struct function. > > > > Oooo, even better. No inline functions. > > > > Like this? > > Aldy > > > > 0001-Disable-threading-through-latches-until-after-loop-o.patch > > > > From ff25faa8dd8721da9bb4715706c662fc09fd4e8c Mon Sep 17 00:00:00 2001 > > From: Aldy Hernandez <al...@redhat.com> > > Date: Thu, 9 Sep 2021 20:30:28 +0200 > > Subject: [PATCH] Disable threading through latches until after loop > > optimizations. > > > > The motivation for this patch was enabling the use of global ranges in > > the path solver, but this caused certain properties of loops being > > destroyed which made subsequent loop optimizations to fail. > > Consequently, this patch's mail goal is to disable jump threading > > involving the latch until after loop optimizations have run. > > > > As can be seen in the test adjustments, we mostly shift the threading > > from the early threaders (ethread, thread[12] to the late threaders > > thread[34]). I have nuked some of the early notes in the testcases > > that came as part of the jump threader rewrite. They're mostly noise > > now. > > > > Note that we could probably relax some other restrictions in > > profitable_path_p when loop optimizations have completed, but it would > > require more testing, and I'm hesitant to touch more things than needed > > at this point. I have added a reminder to the function to keep this > > in mind. > > > > Finally, perhaps as a follow-up, we should apply the same restrictions to > > the forward threader. At some point I'd like to combine the cost models. > > > > Tested on x86-64 Linux. > > > > p.s. There is a thorough discussion involving the limitations of jump > > threading involving loops here: > > > > https://gcc.gnu.org/pipermail/gcc/2021-September/237247.html > > > > gcc/ChangeLog: > > > > * tree-pass.h (PROP_loop_opts_done): New. > > * gimple-range-path.cc (path_range_query::internal_range_of_expr): > > Intersect with global range. > > * tree-ssa-loop.c (tree_ssa_loop_done): Set PROP_loop_opts_done. > > * tree-ssa-threadbackward.c > > (back_threader_profitability::profitable_path_p): Disable > > threading through latches until after loop optimizations have run. > > > > gcc/testsuite/ChangeLog: > > > > * gcc.dg/tree-ssa/ssa-dom-thread-2b.c: Adjust for disabling of > > threading through latches. > > * gcc.dg/tree-ssa/ssa-dom-thread-6.c: Same. > > * gcc.dg/tree-ssa/ssa-dom-thread-7.c: Same. > Hi, This last test now fails on aarch64: FAIL: gcc.dg/tree-ssa/ssa-dom-thread-7.c scan-tree-dump thread3 "Jumps threaded: 8" Can you check? Thanks, Christophe OK > jeff > >
