[LLVMdev] How to get LoopInfo within Pass subclass?

[Michael McCracken]

On Aug 5, 2004, at 8:11 PM, Chris Lattner wrote:
>
> Sure, you can do that.  Just use F->getParent() to get to the Module.

D'oh. OK, so I can do what I need with a hack for now.

>> Also, out of curiosity, why the stateless restriction - is it because
>> passes may someday be run in parallel?
>
> Yup, exactly.  That and we want to be able to make multiple instances 
> of a
> function pass at the same time (e.g. loop info for a module pass) 
> without
> the function pass breaking.

Right.

> We have no problem with people asking questions.  :)  The PassManager 
> is
> actually do for a rewrite.  The current implementation is a nasty
> templated monster in lib/VMCore/PassManagerT.h.  If you'd like to work 
> on
> it, all you need are some C++ experience, little shame in asking
> questions, and an understanding of the passmanager.  Also, there is 
> some
> info in this bug that may be useful:  http://llvm.cs.uiuc.edu/PR36

Well, I took a look at it a bit over the weekend. I am probably not the 
right person to do the complete rewrite, for instance reworking the 
Pass class hierarchy doesn't sound like something I'd want to do. Just 
getting to this point has been a bit of an education in real C++.

However, I would be willing to try just adding support for Module 
passes requiring Function passes, and hopefully that work wouldn't be 
wasted when the eventual rewrite does occur.

Here's what I see: We have a modulepass MP that needs a functionpass 
FP. We need a copy of that FP (and every pass it depends on) for each 
function in the module that MP is being run on.

Currently, in add() we only create one instance of FP, on which we then 
call addToPassManager() so we can get the right call to addPass(FP, 
...), which adds FP to a single Batcher, in this case, a 
PassManagerT<FunctionPass>. In addPass(MP, ...) we see the FP in the 
required set, and attempt to mark it as used by the MP. We don't find 
it in markPassUsed though, because FP was never added to 
CurrentAnalyses. It was just added to the Batcher.

So here's some changes that look necessary. This is likely to be an 
oversimplified view, but hopefully it's a start.

1 - in add(), discover that the pass we're requiring is a subpass, and 
create more of them.
This is the natural place to do it, but can we do this here, or do we 
not know enough about the passes?

2 - in addPass(SubPassClass, ...), add those FPs to CurrentAnalyses.
Should we have a map of BatcherClasses - (function, BatcherClass) pairs 
instead of just one BatcherClass?

3 - Provide API for the MP to get an analysis per function. (generally, 
for the PassClass to get analysis per SubPassClass):

Instead of this:
getAnalysis<PassType>()
the natural thing would seem to be (for PassClass = MP and SubPassClass 
= FP):
getAnalysis<PassType>(Function)

This simple change does mean some big moving in the background, though, 
since (for starters) the PassInfoMap can't just key on the TypeInfo 
anymore.
It will need to key on something like a structure with TypeInfo and the 
unit of code that the pass is attached to. I have a feeling there are 
similar instances where PassInfo needs code-unit info attached to it...

Any comments/clarifications/suggestions?

-mike