Preliminary patch for PR23820 and PR24309

Richard Guenther richard.guenther@gmail.com
Fri Oct 12 21:21:00 GMT 2007


On 10/12/07, Sebastian Pop <sebpop@gmail.com> wrote:
> 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.

loop header copying is run after the first VRP pass, but DOM usually
catches this.  Now in this case DOM needs enabling transformations.

Why do we run loop header copying so late?  If it doesn't cause
problems if would run it as first optimization after inlining (which
obviously fixes the problems you see, the first VRP pass removes
the comparison).  The last place in the pass pipeline that still
works is just before FRE.

Richard.



More information about the Gcc-patches mailing list