This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Preliminary patch for PR23820 and PR24309
Hello,
> 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.
yes, these blocks cannot be removed as long as we keep the loops in
the shape when latch has just one successor. They are removed once
we no longer update the loops. I am not sure, do you suggest that
we should not do this, or why are you asking? Certainly, the
presence of the empty latch block does not make the analysis in ltrans
any harder (not any simpler, of course).
> 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.
Yes, this seems to be the right 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.
Both VRP and DOM should be able to eliminate such a condition, already.
Zdenek