[LLVMdev] Pass Manager Restriction?

[Devang Patel]

On Apr 10, 2009, at 12:42 PM, Joseph Blomstedt wrote:

> Good to know. I was referencing a local copy of 2.3 docs which didn't
> include the "does not require any module passes" statement. It appears
> the docs were changed two days before 2.4 was released in November. I
> suppose I should update my docs more often.
>
> Are there any plans to change this restriction, or any best practices
> to get similar behavior?

There are any any plans to change this restriction at the moment. The  
best option is to avoid writing a module pass that requires function  
pass.

> Since immutable pass is a subclass of module
> pass, this problem extends to immutable passes as well. In particular,
> any function pass that requires AliasAnalysis or
> MemoryDependenceAnalysis (which in turn requires AliasAnalysis) can no
> longer be used in a following module pass (even if the basic alias
> analysis is used, which is an immutable pass). This makes
> inter-procedural transformations/analysis that depends on memory
> dependence information difficult to achieve. I've worked around the
> problem by partitioning my passes into two sets which are run serially
> and share relevant information through an external structure on the
> heap, but that completely kills the benefit of the pass manager and
> having LLVM manage the lifetime of analysis information automatically.
>
> In short, I'm just surprised this type of chaining doesn't appear in
> the existing set of LLVM passes. Is there an obvious way to
> restructure passes that I'm missing?

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

-
Devang