[Bug tree-optimization/83410] [8 regression] libgomp.graphite/force-parallel-4.c etc. FAIL

["law at redhat dot com" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83410

Jeffrey A. Law <law at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2

--- Comment #3 from Jeffrey A. Law <law at redhat dot com> ---
So I'm not at all familiar with the graphite bits, but it looks like we're
threading in this loop:

N is 1500.


     for (j = 0; j < N; j++)
        {
          if (j > 500)
            {
              x[i][j] = i + j + 3;
              y[j] = i*j + 10;
            }
          else
            x[i][j] = x[i][j]*3;

The threading causes the loop by bypass the loop exit test the first 500
iterations of the loop.  Essentially the test within the loop that j > 500
makes the test to exit the loop redundant on the first 500 iterations.

That transformation seems to cause graphite to ignore the loop.  Presumably the
bypassing of the loop exit test changes the form of the loop into something
that graphite just doesn't like.

It certainly raises the question of whether threading should only thread
through the exit test if the ultimate destination is outside the loop (which
has the effect of changing the loop exit test block and removing one or more
blocks from the loop when it applies).

When the ultimate destination is inside the loop, then we may likely be mucking
up the loop in ways that unswitching and other restructuring optimizations do
not like.

Let me ponder that a bit as well as how to detect.