[LLVMdev] PassManager

[Chris Lattner]

On Tue, 7 Nov 2006, Vikram Adve wrote:
> I read Chris's notes so I got all this information there already.  My
> comments were in response to that.

It's unclear what you're missing then: fusion can be easily handled by the 
framework.  Unimodular transform support is orthogonal to the pass 
framework and could be built as a later step.  Am I misunderstanding your 
question?

-Chris

> 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
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/