[LLVMdev] PassManager

[Chris Lattner]

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.  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.

-Chris

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