newbie question - selecting the write kind of pass

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.

If I got it right, I create a new AnalysisGroup, and write a pass that
implements it. What kind of pass should I derive it from? The mapping
only makes sense within a function, so FunctionPass seems to be the
right choice ... is that correct?

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? Since all passes will act on one function
at a time, the life of the analysis will be handled correctly, right?

Sameer.

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?

If I got it right, I create a new AnalysisGroup, and write a pass that
implements it. What kind of pass should I derive it from? The mapping
only makes sense within a function, so FunctionPass seems to be the
right choice ... is that correct?

Yes.

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.

Since all passes will act on one function
at a time, the life of the analysis will be handled correctly, right?

Yup!

-Chris

> 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 :slight_smile:
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.

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 :slight_smile:
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 :slight_smile:

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

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
:slight_smile:

Ah ok ... I assumed a standard policy of "all stupid questions will be
answered in kind" :wink:

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! :slight_smile:

Sameer.