[LLVMdev] PassManager

[Vikram Adve]

Devang,

I read Chris's notes so I got all this information there already.  My  
comments were in response to that.

--Vikram
http://www.cs.uiuc.edu/~vadve
http://llvm.cs.uiuc.edu/


On Nov 7, 2006, at 12:34 PM, Devang Patel wrote:

> Hi Vikram,
>
> On Nov 7, 2006, at 10:19 AM, Vikram Adve wrote:
>
>> Chris and Devang,
>>
>> Before you implement the LoopPassManager class, I'd like to discuss
>> this a little bit.  I have a suggestion and a question; we can
>> discuss this now or later, as you wish:
>>
>> 1. The LoopPassManager might become much simpler if the more complex
>> loop passes are given control over how they iterate over the loops,
>> rather always rely on the manager to enumerate the loops in some
>> fixed order.  Then the pass could be responsible for making sure that
>> it handles issues like loops that are deleted during the pass.
>
> LoopPassManager will manage the LoopInfo. It will maintain loop
> priority queue and expose APIs to add/remove loops that
> transformations can use.
>
>
>> For
>> example, some algorithms make internal decisions about which loops to
>> handle together and also what order to visit them.  For example, the
>> LoopFusion class may need to inspect loop headers to decide which
>> subsets of loops to fuse and then fuse them as it goes.
>
> LoopPassManager will expose two virtual methods.
>
> 1) runOnLoop(Loop &L, LoopPassManger &LPM)
>
>       Loop transformation can override to process this particular  
> loop.
>
> 2) runOnFunctionBody(Function &F, Loop&L, LoopPassManager &LPM)
>
>      LoopFusion and others can override this to to analyze and process
> multiple loops.
>
>>
>> I think you could do this just by adding an iterator method somewhere
>> that enumerates sets of loops (i.e,. returns a vector of Loop
>> objects).  The bottom-up iterator could just be a default choice.
>>
>> 2. The question is how you plan to handle unimodular
>> transformations.  I think it's a very nice abstraction and a number
>> of loop transforms should be implemented using that rather than more
>> ad hoc code, e.g., interchange, reversal, skewing.  But that requires
>> implementing support for unimodular transforms before those passes
>> are implemented.
>
> I have not yet spent enough time to think about unimodular
> transformation framework implementation.
>
> -
> Devang
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev