[LLVMdev] Pass Manager Restriction?

[Devang Patel]

Hi Nick,

I meant to say "there are not any immediate plans", I did not mean to  
say "never ever". The facility to use function pass, in a limited  
scope,  from a module pass was introduced recently (IIRC, after 2.0  
release).

On Apr 10, 2009, at 2:54 PM, Nick Johnson wrote:

> On Fri, Apr 10, 2009 at 5:24 PM, Devang Patel <dpatel at apple.com>  
> wrote:
>> ...  because usually a module pass operates on entire module (e.g.
>> inliner) and it does not require information specific to a function.
>> If your pass need info collected by a function pass then why not
>> structure your pass as a function pass and run it for all function in
>> a module ?
>
> I very much disagree with this reasoning.  The ``level'' of a
> pass---module, loop, function, whatever---should have more to do with
> making the algorithm legible than with restricting its scope.
>
> We often write a FunctionPass or a LoopPass because it is the most
> natural way to express the analysis or transformation, not because the
> information gathered are localized.

It has to do with how analysis information is managed. The pass  
manager itself does not store any info. The analysis information is  
collected and maintained by respective passes.

Normally, if a function pass FP1 requires inform from function pass  
FP0 then all pass manager does is ensure that for each function FP0 is  
run before FP1. Simple. Now, FP1 can query FP0 for the function it is  
operating on.

However when the module pass request such information, the pass  
manager MP1 asks function pass FPO to generate this information on the  
fly for the given function. There is not any mechanism to maintain  
function analysis info generated by FP0 for all functions.  
MemoryDependenceAnalysis will only keep info for the last function it  
analyzed.

>  My research group has many
> function-level transformations which are loosely-coupled with
> loop-level analyses.

Are your pass using loop info or manipulating loops ? If they are  
manipulating loops then they are loop-level transformations.  
Otherwise, they can request LoopInfo, which is a function pass.

-
Devang

>  For example, multi-threaded code generation (1)
> splits an arbitrary *function* into multiple threads, but requires a
> partition.  Decoupled software pipelining (2) generates such a
> partition by analyzing a *loop*.  At the moment, we implement
> decoupled software pipelining as a function pass, even though we think
> the code would be more maintainable as a loop pass.
>
> And what about Immutable passes, such as TargetData?  They are
> technically ModulePasses.  But if you schedule passes in the incorrect
> order, llvm will try to instantiate a new TargetData in a private pass
> manager, causing an assert.
>
> I think the notion of ``levels'' of passes is artificial, unintuitive,
> and unnecessary.
>
> -- 
> Nick Johnson
>
> (1) Multi-threaded Code Generation:
> http://liberty.princeton.edu/Publications/micro40_gmtis.pdf
> (2) Decoupled Software Pipelining:
> http://liberty.princeton.edu/Publications/micro38_dswp.pdf
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev