On Wed, Sep 8, 2021 at 3:25 PM Aldy Hernandez <al...@redhat.com> wrote: > > > It would be helpful to have the patch causing the issue to look at the IL. > > But as Micha said, there needs to be a perfect loop nest for interchange > > to work. > > > > Richard. > > Absolutely! I'm attaching the reduced testcase, as well as the patch. > > The problematic thread shows up in the thread2 dump: > > Checking profitability of path (backwards): bb:3 (4 insns) bb:9 (0 > insns) bb:5 > Control statement insns: 2 > Overall: 2 insns > Registering FSM jump thread: (5, 9) incoming edge; (9, 3) (3, 8) > nocopy; (3, 8)
Well, so as Micha said, the threading destroys the outer loop by making it have two entries - we actually _do_ recover from this but it results in a non-empty latch of the outer loop and thus the loop is no longer a perfect nest. The interchange pass has special-sauce to recover from the loop store motion applied but not to handle the kind of loop rotation the jump threading caused. The forward threader guards against this by simply disallowing threadings that involve different loops. As I see the threading done here should be 7->3 (outer loop entry) to bb 8 rather than one involving the backedge. Also note the condition is invariant in the loop and in fact subsumed by the condition outside of the loop and it should have been simplified by VRP after pass_ch but I see there's a jump threading pass inbetween pass_ch and the next VRP which is likely the problem. Why does jump threading not try to simplify a condition before attempting to thread through it? After all ranger should be around? Richard. > Thanks. > Aldy
