[Bug middle-end/40029] [4.5 Regression] Big degradation on swim/mgrid on powerpc 32/64 after alias improvement merge (gcc r145494)

["rguenth at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #2 from rguenth at gcc dot gnu dot org  2009-05-21 14:04 -------
That's

      DO 100 J=1,N
      DO 100 I=1,M
      CU(I+1,J) = .5D0*(P(I+1,J)+P(I,J))*U(I+1,J)
      CV(I,J+1) = .5D0*(P(I,J+1)+P(I,J))*V(I,J+1)
      Z(I+1,J+1) = (FSDX*(V(I+1,J+1)-V(I,J+1))-FSDY*(U(I+1,J+1)
     1          -U(I+1,J)))/(P(I,J)+P(I+1,J)+P(I+1,J+1)+P(I,J+1))
      H(I,J) = P(I,J)+.25D0*(U(I+1,J)*U(I+1,J)+U(I,J)*U(I,J)
     1               +V(I,J+1)*V(I,J+1)+V(I,J)*V(I,J))
  100 CONTINUE

right?

4.4 can do predictive commoning on it while trunk can't - this also unrolls
the loop twice.  On trunk we are likely confused by PRE that already
partially performs what predictive commoning would do.  Disabling PRE
makes predictive commoning work but doesn't unroll the loop (same as
with disabling PRE in 4.4).  It is likely the full redundancies PRE
discovers that cause the unrolling.

That said - this looks like yet another unfortunate pass ordering problem
to me.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2009-05-21 14:04:13
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40029