llvm dev - Apr 2005 - [LLVMdev] newbie question - selecting the write kind of pass

On Sat, Apr 02, 2005 at 11:35:30AM -0600, Chris Lattner wrote:
> On Sat, 2 Apr 2005, Sameer D. Sahasrabuddhe wrote:
> > I want to create a simple map from a Value to the instruction that
> > defines it. Such a map is present inside SchedGraph, but I need it in
> > a much simpler context.
> 
> Is this in the context of the code generator?
No ... I am just trying to feel the waters ... simply trying to create
a "data flow graph" from the SSA form. I meant "context" in
a very
loose, plain-English way.
> > The documentation says that "a FunctionPass is not allowed to
retain
> > state across functions. What does that imply for an Analysis pass
> > derived from FunctionPass?
> 
> Yes.
Ummm ... let me rephrase my question :)
An analysis pass derived from a FunctionPass is not expected to retain
state across functions. What exactly does that mean when the passes
are being run on the program? I assume that analysis will be
instantiated only once, and used everywhere. If that is so, as the
pass writer, do I have to "flush" all data-structures from the
previous run, in runOnFunction?

Sameer.
-- 
Research Scholar, KReSIT, IIT Bombay
http://www.it.iitb.ac.in/~sameerds/

On Sun, 3 Apr 2005, Sameer D. Sahasrabuddhe wrote:
> On Sat, Apr 02, 2005 at 11:35:30AM -0600, Chris Lattner wrote:
>
>> On Sat, 2 Apr 2005, Sameer D. Sahasrabuddhe wrote:
>>> I want to create a simple map from a Value to the instruction that
>>> defines it. Such a map is present inside SchedGraph, but I need it
in
>>> a much simpler context.
>>
>> Is this in the context of the code generator?
>
> No ... I am just trying to feel the waters ... simply trying to create
> a "data flow graph" from the SSA form. I meant
"context" in a very
> loose, plain-English way.
Ah, ok.  Well in this case, the function describing the mapping from a 
Value* to the instruction that defines it is the identity function.  Given 
a Value*, you can do something like this:

Value *V = ...

if (Instruction *I = dyn_cast<Instruction>(V)) {
   ... V is the result of the instruction I ...
} else {
   ... V is some other sort of value, such as a constant or a formal
   argument ...
}
>>> The documentation says that "a FunctionPass is not allowed to
retain
>>> state across functions. What does that imply for an Analysis pass
>>> derived from FunctionPass?
>>
>> Yes.
>
> Ummm ... let me rephrase my question :)
> An analysis pass derived from a FunctionPass is not expected to retain
> state across functions. What exactly does that mean when the passes
> are being run on the program? I assume that analysis will be
> instantiated only once, and used everywhere. If that is so, as the
> pass writer, do I have to "flush" all data-structures from the
> previous run, in runOnFunction?
Ah whoops, right, I uh did an incredibly poor job answering your question 
:)

You have it exactly right.  Currently if you have a function pass, it is 
created once per function, and any other functionpass that requires it 
will see its results.  The pass manager tells your pass that all clients 
are done with it by calling the releaseMemory method:
http://llvm.cs.uiuc.edu/docs/WritingAnLLVMPass.html#releaseMemory

That is the place you should "flush" the contents of the analysis.

-Chris

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

On Sat, Apr 02, 2005 at 09:44:40PM -0600, Chris Lattner wrote:
> Ah, ok.  Well in this case, the function describing the mapping from a 
> Value* to the instruction that defines it is the identity function.  Given 
> a Value*, you can do something like this:
> 
> Value *V = ...
> 
> if (Instruction *I = dyn_cast<Instruction>(V)) {
>    ... V is the result of the instruction I ...
> } else {
>    ... V is some other sort of value, such as a constant or a formal
>    argument ...
> }
Thanks for that! A closer inspection of the Programmer's Manual
revealted this:

  One important aspect of LLVM is that there is no distinction between
  an SSA variable and the operation that produces it. Because of this,
  any reference to the value produced by an instruction (or the value
  available as an incoming argument, for example) is represented as a
  direct pointer to the instance of the class that represents this
  value. Although this may take some getting used to, it simplifies
  the representation and makes it easier to manipulate.

This is kinda tucked away in a corner, but should in fact be the first
thing to be said about the Value class!
> Ah whoops, right, I uh did an incredibly poor job answering your question 
> :)
Ah ok ... I assumed a standard policy of "all stupid questions will be
answered in kind" ;)
> http://llvm.cs.uiuc.edu/docs/WritingAnLLVMPass.html#releaseMemory
> That is the place you should "flush" the contents of the
analysis.
Thanks.

Unsuppressable rave: After months spent in MachSUIF prison, LLVM is
truly liberating ... everything falls together perfectly ... if you
think something should be present in a certain way, you can bet that
it already is! :)

Sameer.
-- 
Research Scholar, KReSIT, IIT Bombay
http://www.it.iitb.ac.in/~sameerds/