[LLVMdev] How to get LoopInfo within Pass subclass?

Chris Lattner sabre at nondot.org
Thu Aug 5 20:11:53 PDT 2004


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/




More information about the llvm-dev mailing list