Tracing Value Dependency Chains

Hello All,

What would be the best way to trace Value Dependency Chains in LLVM. Can I use some API to perform this?

The use-def chain process mentioned at http://llvm.org/docs/ProgrammersManual.html#iterate_chains will just get the values (Operands) being used in the current Instruction. For getting the values operands in the particular instruction are influenced from I have to recursively call the use-def on these operands. I was wondering if there is already available better way of doing this in LLVM.

Thanks,
Manish

It would be great help if someone can point me to similar code in Analysis or Transform, i.e. tracing value dependencies chains.

Thanks,
Manish

It would be great help if someone can point me to similar code in Analysis or Transform, i.e. tracing value dependencies chains.

If I understand correctly, given an instruction I, you want to find its operands o1 through oN, and then find the instructions (or LLVM values) that generate the values o1 through oN, and then find the instructions generating those values, etc, etc. In other words, you want to take a static backwards slice of an instruction. Is this correct?

I don’t know of code within LLVM that does this, but I’ve written code to take an inter-procedural static backwards slice (only through SSA values; loads are not matched up to potential stores). If that’s what you need, I can ask my advisor if we can release that code to you.

Also, would others find it useful to have this code? I think this is the second or third time someone’s asked for backwards static slicing code.

– John T.

Hey John,

Yes this is what I am looking for. I wrote a code as I described in my first mail and I am getting desired result except when the chain encounters load instruction (you have also mentioned the that u skip loads).

I think the recursive trace back for a Value V depending on Operands (o1,…oN) should terminate at the nearest definition of the oN (i.e. it is not an instruction but a LLVM Type). Right? If you can release the code that would be a great help.

Thanks,
Manish

Hey John,

Yes this is what I am looking for. I wrote a code as I described in my first mail and I am getting desired result except when the chain encounters load instruction (you have also mentioned the that u skip loads).

Okay. Just out of curiosity, is your static slice local (stopping at function arguments) or inter-procedural? Do you need an inter-procedural slice? I have code that does both.

I think the recursive trace back for a Value V depending on Operands (o1,…oN) should terminate at the nearest definition of the oN (i.e. it is not an instruction but a LLVM Type). Right?

No. The operands are not types. They are LLVM values (llvm::Value *'s) and could be instructions (Instruction *), Constants (Constant *), function arguments (Argument *), or any other object whose class derives from llvm::Value.

Regarding the idea of nearest definition, remember that the LLVM IR is in SSA form. Each value (remember that all operands are Value *'s) has a single definition. There is no nearest definition of a value because each value is only defined once.

If you can release the code that would be a great help.

I’ll ask my advisor.

– John T.

Hey John,

Yes this is what I am looking for. I wrote a code as I described in my first mail and I am getting desired result except when the chain encounters load instruction (you have also mentioned the that u skip loads).

Okay. Just out of curiosity, is your static slice local (stopping at function arguments) or inter-procedural? Do you need an inter-procedural slice? I have code that does both.

Manish: My code is currently tracing local dependencies and I am running a basic Function Pass. My first aim to trace local dependencies later I will work on inter-procedural static slice. So if your advisor allows to share, for now static slice local would be enough.

I think the recursive trace back for a Value V depending on Operands (o1,…oN) should terminate at the nearest definition of the oN (i.e. it is not an instruction but a LLVM Type). Right?

No. The operands are not types. They are LLVM values (llvm::Value *'s) and could be instructions (Instruction *), Constants (Constant *), function arguments (Argument *), or any other object whose class derives from llvm::Value.

Regarding the idea of nearest definition, remember that the LLVM IR is in SSA form. Each value (remember that all operands are Value *'s) has a single definition. There is no nearest definition of a value because each value is only defined once.

Manish: I described my method incorrectly. My aim of getting all the Values that effect a particular instruction I is to see which Type of program variables effect a particular Instruction. Say an Instruction I is effected by Operands (o1,…,oN).
I ← (o1,…,oN) . All these o’s are LLVM Values, but some of them might be Instructions again. So for those Values which are Instructions get the operands it is effected by, keep doing it until operand is not an instruction. Now from the list of effecting operands I can get the list Value Types and TypeIDs effecting this particular instruction I . Please let me know if you get the idea of what i am trying to do?

If you can release the code that would be a great help.

I’ll ask my advisor.

Manish: Great!! Thanks