[LLVMdev] [PATCH] Split LoopUnroll pass into mechanism and policy

[Dan Gohman]

On May 7, 2008, at 1:08 AM, Matthijs Kooijman wrote:

> Hi Dan,
>
>> This should still make it easy to write new unrolling passes with
>> custom heuristics, but it would also be more flexible for passes to
>> do unrolling in combination with other transformations.
> Agreed.
>
> To shed some light on my specific requirements, I am working with an
> architecture that has only limited support for loops and control  
> flow. This
> means that loop unrolling is not a matter of performance, but any  
> loop that
> can't be mapped on the architecture must be unrolled to be able to  
> work. So,
> I don't really need the added flexibility, though I agree that it is  
> a good
> idea nonetheless.

Ok.

>
>
>
> Splitting off the second part of unrollLoop (the actual unrolling,  
> after
> deciding to unroll the loop) shouldn't be a problem. I am a bit  
> concerned
> about the first part (before the decision), which finds out the trip  
> count and
> trip multiple. Since both policy and mechanism need these values,  
> that code
> must be shared somehow as well. I see two options for that:
> 1. Put two methods in the utility class, each of which return one of  
> those
>    values.
> 2. Add two methods to the Loop class. Currently, there is a  
> getTripCount()
>    method that returns the trip count as a Value*. Perhaps we could  
> add a
> 		getTripCountConst() (or getTripCountInt() ?) and  
> getTripCountMultiple() to
> 		Loop?

>
>
> It seems to me the second option is nicer, though it shouldn't make  
> too much
> of a difference.

The second option sounds nicer to me too. Is the name
getSmallConstantTripCount too paranoid?

>
>
> Furthermore, where to put this utility class? lib/Transforms/ 
> UnrollLoop.cpp
> seems reasonable?

Transform utilities can go under lib/Transforms/Utils. :-)

Dan