This is the mail archive of the gcc@gcc.gnu.org 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]

Re: Re-run of loop pass


[ Because I invented this hack, it's appropriate I write an
  apology on it - however, don't expect a Platonesk Dialogue ]

>  What's the philosophy of rerunning the loop optimisation
>  pass twice?

It's a poor man's device to cover up that the various *_giv  
routines in loop.c can't handle general induction variables of the  
form CONSTANT + INVARIANT + BIV * INVARIANT.  To quote my own  
message to the egcs mailing list (before it went public - you won't  
find this in the archives):

<QUOTE>
2. GIVs of the form (INVARIANT * BIV + INVARIANT + CONSTANT) are  
not recognised by strength reduction.

These givs are generated in the address expressions resulting from  
accessing arrays that are not 0-based.  Because Fortran arrays that  
are not explicitly declared as being 0-based are 1-based, strength  
reduction is not very effective for loops in Fortran (in fact, part  
of the above expression is reduced).

Short term solution - run loop optimisation twice to get the  
expression completely reduced.

Long term solution:  Make the various *_giv_* routines in loop.c  
recognise the above expression as a giv - this might not even be  
hard for the person who _wrote_ those routines in the first place.
</QUOTE>

>  I've noticed that this can generate poorer code when
>  unrolling loops or using the bct optimisation if a BIV
>  is eliminated on the first pass.

I do not completely understand this remark.  The sequence is:

first-pass-through-loop; second-pass-through-loop;  
pass-through-unroll; bct-optimisations.

How can the elimination of a BIV be so important then ?  It can  
either happen in the first or the second pass through loop, but that  
shouldn't matter.

>  On the second pass, loop_iterations is often unable to
>  determine the iteration count for loops with limits that
>  should be able to be determined at compile time.  Loop
>  unrolling or the bct optimisation then makes a dog's
>  breakfast of things.

Do you have an example of this at hand ?  I fail to see how this  
could be happening.

Thanks,
Toon.


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