This is the mail archive of the
mailing list for the GCC project.
Re: Preliminary patch for PR23820 and PR24309
On 10/11/07, Zdenek Dvorak <email@example.com> 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
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.