[LLVMdev] Pass Manager Restriction?

[Nick Johnson]

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.  My research group has many
function-level transformations which are loosely-coupled with
loop-level analyses.  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