Hi,
Well, I ran into an exactly same problem some days back. The problem
may lies in the fact that the store instruction does not have a name
for its value, thus one can't really use a use-def iterator on the
instruction itself.
So, i tried a work around this, and it worked..
Basically, i check if the instruction is a store instruction, and if
the first/second operand (which ever u want to iterate on, the first
one is for the defs, and the second one is for the uses, since the
value of first operand is stored in second) is an Instruction, one can
iterate over the def-use tree easily.
So implementation wise speaking..
.
.
if (StoreInst* storeInst = dyn_cast<StoreInst>((*UI))) // If a store
Instruction is found
{
cerr << " ### StoreFOUND " << *storeInst << "\n";
Instruction &stInst = *Keep;
if (Instruction *Op = dyn_cast<Instruction>(stInst.getOperand(0))) //
if the first operand is an instruction
{
IterateOverDef(Op); // Iterate over the definitions of this Instruction
}
}
.
.
Also, note that the llvm IR is in the SSA form, the def-use chain
length is 1, one definition and its use (except with the variables
with multiple uses).. so if you want to iterate over or make a def-use
tree for the whole module/function/basic block, you have to write a
recursive routine, which steps over a def-use tree at a time.
Programmers’ manual says we can iterate over a use-def chain by op_iterator.
It works fine except for load and store instruction of stack variables.
For example, a simple bitcode is like the below.
i = alloca i32
store i32 0, i32* %i, align 4
%tmp1 = load i32* %i, align 4
If I apply a use-def chain to load instruction, I get alloca instruction.
I think store instruction is a correct use-def chain.
Am I right?
Is there any other method to iterate over a use-def chain in this case?
The op_iterator will tell you what definitions the instruction uses. So in this case, the "alloca" instruction is the correct one because the store instruction isn't defining %i. If you were to iterate over the uses of the alloca instruction, then you would get the "store" and "load" instructions.
If you're trying to determine that %i is the same value for both the "store" and "load" instructions, then you'll probably want to compare the op_iterator values for both the "store" and "load" and see if they match. For example, %i in this case matches, because %i isn't redefined between the store and the load.
You should try out Owen’s MemDepAnalysis interface, which returns the load/store that another load/store depends on. Note that this is a fuzzy query: it depends on the precision of alias analysis.