Preliminary patch for PR23820 and PR24309

[Sebastian Pop]

On 10/11/07, Zdenek Dvorak <rakdver@kam.mff.cuni.cz> wrote:
>
> cfg cleanup does that in gcc.
>

That's not helping removing these BBs as they are just before a BB
with more than one entry, so they are considered as loop latch BBs.

I'm still thinking about how to adapt the analyzer to not reject
ltrans-3.c and not to fail on the two PRs, but the pattern in these
three cases is exactly the same, I cannot distinguish in between: all
the statements outside the innermost loop are just either conditions,
or the update of the main induction variable.

I would like to have a more strict definition of perfectly nested
loops, by forbidding more than a COND_EXPR in the body of the outer
loops: i.e. the only COND_EXPR of the outer loop should be the exit
condition.  But this is too strict for the case in ltrans-3.c.

Do we have an option to XFAIL ltrans-3.c?  And of course, file an
optimization PR for the following problem:

The code for ltrans-3.c is

double u[1782225];
int foo(int N, int *res)
{
  unsigned int i, j;
  double sum = 0;
      for (i = 0; i < N; i++)
	{
	  for (j = 0; j < N; j++)
	    {
	      sum = sum + u[i + 1335 * j];
	    }
	}
      *res = sum + N;
}

we check that N != 0 before entering the first loop, and also inside
this loop, we check for the exact same expression N != 0 before
entering the innermost loop.  N not being modified in between these
two checks, the second cond_expr is redundant.  VRP or a constant
propagator could be adapted to optimize this kind of double checking.

Sebastian