Re-run of loop pass

[Toon Moene]

I wrote:

T > [ Rerunning loop optimisation pass ... ]

T > The interesting thing about loop unrolling in this context is, that  
T > we deliberately moved it to *after* the second loop opt phase
T > because it suffered badly from GIVs resulting from loop unrolling  
T > being found and reduced by the second loop opt pass.  Now that GIV  
T > combining is in full force, this might not be necessary anymore:

T >       DO I = 1, N, 4
T >          X(I  ) = X(I  ) + Y(I  )
T >          X(I+1) = X(I+1) + Y(I+1)
T >          X(I+2) = X(I+2) + Y(I+2)
T >          X(I+3) = X(I+3) + Y(I+3)
T >       ENDDO

T > would previously lead to 8 registers being used for addressing,  
T > against 2 now.

Michael:

>  I've done some experimentation with this code snippet.
>  With -funroll-loops or BCT optimisation the generated
>  code is _attrocious_ since the constant iteration count
>  cannot be determined.  The patch at the end seems to fix
>  this problem (it could be generalised but for most cases
>  this may not be necessary).  Could someone test this on
>  a host machine with autoincrement addressing (such as
>  the 68k)?

I think we're talking at cross purposes - the above code doesn't  
have a constant iteration count.  The iteration count is N / 4 iff N  
% 4 == 0 (in fact, the code as shown assumes this).  The code was  
just meant to show why we're running loop unrolling *after* the  
second pass through loop opt ...

If -funroll-loops nevertheless generates worse code, than that's  
due to something I haven't foreseen.

HTH,
Toon.