------- 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
