[LLVMdev] Pass Manager Restriction?
Nick Johnson
npjohnso at cs.princeton.edu
Fri Apr 10 14:54:46 PDT 2009
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
More information about the llvm-dev
mailing list