[LLVMdev] PassManager

Vikram Adve vadve at cs.uiuc.edu
Tue Nov 7 12:33:01 PST 2006


On Nov 7, 2006, at 2:02 PM, Chris Lattner wrote:

> On Tue, 7 Nov 2006, Vikram Adve wrote:
>> 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.  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.
>
> I think I see the issue here.  The point of the pass manager (in  
> general)
> is for passes to *give up control* over iteration order in order for
> obtain something else.


Right, I understand that.  I think that works fine in most cases.   
For loop passes, though, this approach is causing some of the  
complexity issues you talked about in your notes.  You could avoid  
them, and also make some loop passes, more natural to write if you  
relaxed this policy and allow a transformation algorithm to choose  
what subsets of loops to visit at a time.


> For example, function passes give up control over
> which order functions are processed in.  This allows pipelining of
> a function through multiple function passes before the next  
> function is
> processed.  If each functionpass could define its own iteration order,
> this wouldn't work.  Note that no generality is lost here: passes that
> don't fit the FunctionPass mold can be made into ModulePasses.
>
> The LoopPassManager is the same thing.  The idea is that the LPM  
> provides
> structured iteration among loop pass classes.  I believe that most  
> loop
> transformations will fit into the framework, and will thus enjoy the
> benefits of it.  Those that don't can alway be FunctionPasses.

Yes, I agree -- you can't and shouldn't try to make LPM handle all  
possible cases.  But if you can make the LoopPassManager more  
flexible and simpler at the same time, that seems worthwhile.

--Vikram




More information about the llvm-dev mailing list