This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [gfortran] Avoid induction variables in DO loops.
On Fri, 2004-10-08 at 14:29, Mark Mitchell wrote:
> Daniel Berlin wrote:
>
> > It still doesn't work.
> > Now dominator optimization decides to replace a loop invariant
> > statement with a loop variant one in the loop exit test, so we can't
> > determine the upper bound.
> > Here is what happens.
> >
> > Before dom runs, we have:
> >
> > Loop preheader:
> >
> > # BLOCK 2
> > ...
> > # mnmin_17 = PHI <mnmin_147(19), mnmin_148(1)>; <-- our friendly
> > loop invariant
> > ...
> > # BLOCK 10 (exit test for inner loop)
> > if (jcheck_327 == mnmin_17) goto <L14>; else goto <L41>;
> > ...
> > # BLOCK 12 (exit test for outer loop)
> > if (icheck_37 == mnmin_17) goto <L45>; else goto <L42>;
> >
> >
> > icheck_37 is the outer loop induction variable, jcheck_327 is the
> > inner one.
> > DOM records the copy "mnmin_17 = jcheck_327" in record_equality.
> >
> > The inner loop exit test dominates the outer loop exit test.
> > Thus, it replaces the outer loop exit test with (on the next copy prop):
> >
> > if (icheck_37 == jcheck_327) goto <L45>; else goto <L42>;
> >
> > Note that it just replaced an loop invariant variable (mnmin_17), with
> > a loop variant variable (jcheck_327).
> >
> > There are a couple ways to fix this.
> > I think the best one would be to extend the logic record_equality uses
> > in picking which one to make a copy of the other to say something like:
> > "If both x and y are ssa_names, and the basic block for the defining
> > statement of x has a greater loop depth than the basic block for the
> > defining statement of y, then we should use y as the copy"
> >
> > That way, things are always replaced with something more loop
> > invariant than it was before.
> > If the loop depths are the same, it makes no difference, as the
> > function says.
> >
> > Jeff, if you agree with this, could you kindly implement it?
>
> From what you say, I agree that this sounds like a good fix for this
> problem.
>
> Jeff, do you think you have any time to work on this? If not, would you
> please let us know?
Daniel has already posted a patch. There's one or two nits, but
it's effectively ready to go.
jeff