Re: Spill code and unrolling

Stephan Ceram a icrit :
> Hi,
>
> I've a question about loop unrolling. Let's assume that you compile
> your program without loop unrolling in advance to check if the loops
> which are candidates for loop unrolling contain any spill code. If so,
> it is very likely that after loop unrolling the contained spill code
> is duplicated by the number of how often this loop is unrolled.




Loop unrolling may be done at many compilation levels; depending when
and where you do it, the impact on spill code is not clear.


>
> Now, I was wondering if it would be a good heuristic for a loop
> unroller to skip loops containing spill code. What do you think?


Sure there is. A useful metric for this would be register saturation
that helps you to keep register pressure under control. If you want to
guarantee that your unrolled loop would not result in spilling, just
use register saturation as a filter to bound the unrolling factor.




> It is also an interesting question, how this scenario will effect
> the program execution time for systems with and without caches.
> Intuitively, I would assume that in a system with data caches, the
> additional spill code will have in total a negative influence on the
> unrolled code. Without data caches, I don't really know what could
> be expected.


Loop unrolling may or may not accelerate the execution time: unrolling
a loop may help the instruction scheduler (at compilation or execution
time), but may hurt I-cache too: either the unrolled loop does no
longer fit in it, or simply it may create new conflict on I-cache with
other codes parts.


For spill code, usually, it is always damaging. It is rare to have a
case when introducing spill code is better that hurting ILP extraction.
So avoid spilling by default, because it may pollute D-cache, and may
also hurt dynamic ILP scheduling if long memory operation are executed.

Return to the comp.compilers page.
Search the comp.compilers archives again.