This is the mail archive of the
mailing list for the GCC project.
Re: [gfortran] Avoid induction variables in DO loops.
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: Daniel Berlin <dberlin at dberlin dot org>
- Cc: gcc-patches Patches <gcc-patches at gcc dot gnu dot org>,fortran at gcc dot gnu dot org,Paul Brook <paul at codesourcery dot com>,law at redhat dot com
- Date: Wed, 6 Oct 2004 15:03:02 -0400
- Subject: Re: [gfortran] Avoid induction variables in DO loops.
- References: <email@example.com> <01522E97-17C9-11D9-A4C8-000D93B1B044@dberlin.org>
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:
# BLOCK 2
# mnmin_17 = PHI <mnmin_147(19), mnmin_148(1)>; <-- our friendly
# 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
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
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
"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
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
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.