Re: [gfortran] Avoid induction variables in DO loops.

[Jeffrey A Law <law at redhat dot com>]

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