Re: More aggressive threading causing loop-interchange-9.c regression

[Richard Biener <richard.guenther@gmail.com>]

On Wed, Sep 8, 2021 at 3:25 PM Aldy Hernandez <aldyh@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