Michael McCracken
2004-Aug-06 01:09 UTC
[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#PassFunctionPassOK. 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/
Michael McCracken
2004-Aug-09 19:59 UTC
[LLVMdev] How to get LoopInfo within Pass subclass?
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/PR36Well, 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