llvm dev - Aug 2004 - [LLVMdev] How to get LoopInfo within Pass subclass?

On Aug 5, 2004, at 5:30 PM, Chris Lattner wrote:
> On Thu, 5 Aug 2004, Michael McCracken wrote:
>
>> Hi, I have a hopefully quick question. I'm writing a Pass that
needs
>> to
>> see a whole module at a time and keep some state, so I subclassed 
>> Pass.
>> However, I want to be able to see the Loops in each Function. Roughly,
>
> ok.
>
>> However, when running I'm informed that:
>>
>> PassManagerT.h:421: failed assertion `getAnalysisOrNullUp(P) &&
>> dynamic_cast<ImmutablePass*>(getAnalysisOrNullUp(P)) &&
"Pass
>> available
>> but not found! " "Perhaps this is a module pass requiring a
function
>> pass?"'
>>
>> I couldn't find a clear explanation of which passes can require
which
>> other ones, and I'm a little confused as to whether what I want is 
>> even
>> possible. How can I say that I want LoopInfo for each Function in my
>> Module?
>
> Unfortunately this is a big missing feature in the pass management 
> system.
> In particular, as the assertion says, a "Pass" cannot yet require
a
> "FunctionPass".  The reason this is tricky is that each (e.g.)
LoopInfo
> instance contains loop information for one function.  When we allow 
> Pass
> objects to require FunctionPass objects, the PassManager will have to
> instantiate one FunctionPass for each function in the module.
>
> This is clearly something that we want to do, but unfortunately we 
> can't
> do it yet.  This is actually mentioned here, though I'm not suprised 
> you
> missed it: :)
> http://llvm.org/docs/WritingAnLLVMPass.html#PassFunctionPass
OK. Yeah, I stopped reading after I saw the first 'future extension'. 
Woops.
> As a work-around you can make your "Pass" object work as a 
> FunctionPass.
> I don't know what this will do to the logic in the pass, but if this 
> is an
> option, it would be the best way to go.
> You're right that FunctionPass's are not supposed to have state 
> (something
> that many people overlook :) ), however, for now, nothing will break 
> if it
> does have state, and this is really the only way around this.
I'm not sure if I can do this. The pass I'm writing is writing info 
about the module and its parts to a file, so I need to see the module, 
if only to print its moduleIdentifier.

I'm not sure if there's a way to get the Module that a Function belongs 
to from within a FunctionPass. If I could do that, and cheat by keeping 
some state, I could do what I want as a FunctionPass. Am I missing 
something, or is that not possible?

Also, out of curiosity, why the stateless restriction - is it because 
passes may someday be run in parallel?
> However, if you want to work on the PassManager, please let us know! :)
This depends. If it's really in my way, I may have little choice. I 
would like to make a contribution, though, and it didn't actually sound 
too bad. Any guess what amount of work that'd be?
Assume I have a passing familiarity with the LLVM architecture, 
slightly rusty average C++ skills, and little shame in asking 
questions. :)

-mike

--
	Michael O. McCracken
	UCSD CSE Ph.D. Student
	mike at cs.ucsd.edu

On Thu, 5 Aug 2004, Michael McCracken wrote:
> > You're right that FunctionPass's are not supposed to have
state
> > (something that many people overlook :) ), however, for now, nothing
> > will break if it does have state, and this is really the only way
> > around this.
>
> I'm not sure if I can do this. The pass I'm writing is writing info
> about the module and its parts to a file, so I need to see the module,
> if only to print its moduleIdentifier.
Ok
> I'm not sure if there's a way to get the Module that a Function
belongs
> to from within a FunctionPass. If I could do that, and cheat by keeping
> some state, I could do what I want as a FunctionPass. Am I missing
> something, or is that not possible?
Sure, you can do that.  Just use F->getParent() to get to the Module.
> 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.
> > However, if you want to work on the PassManager, please let us know!
:)
>
> This depends. If it's really in my way, I may have little choice. I
> would like to make a contribution, though, and it didn't actually sound
> too bad. Any guess what amount of work that'd be? Assume I have a
> passing familiarity with the LLVM architecture, slightly rusty average
> C++ skills, and little shame in asking questions. :)
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

If you'd rather not work on it, that's also cool.  Someone will
eventually
get to it, though it's not on anyones "short list" AFAIK.

-Chris

-- 
http://llvm.cs.uiuc.edu/
http://nondot.org/sabre/

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