This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

Oh, and just so people know this is worthwile, if i make record_equality record teh eq values the other way around by brute force, it gfortran properly performs the loop interchange we want on swim, as NAG does.


On Oct 6, 2004, at 2:53 PM, 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:

# 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?
I'd do it, but the whole prev_x and prev_y stuff is a little hard to follow.
It looks like you swap it, but keep the old value, and then passes the old value to record_const_and_copy.
But i'm not positive, and i don't want to muck up the function.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]