[LLVMdev] Tracing Value Dependency Chains

[Manish Gupta]

On Thu, Aug 4, 2011 at 12:57 PM, John Criswell <criswell at illinois.edu>wrote:

>  On 8/4/11 2:45 PM, Manish Gupta wrote:
>
> 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

>
>
> -- John T.
>
>
>
>  Thanks,
> Manish
>
> On Thu, Aug 4, 2011 at 12:14 PM, John Criswell <criswell at illinois.edu>wrote:
>
>>  On 8/4/11 1:53 PM, Manish Gupta wrote:
>>
>> 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.
>>
>>
>>  Thanks,
>> Manish
>>
>> On Wed, Aug 3, 2011 at 10:47 AM, Manish Gupta <manishg at cs.ucsd.edu>wrote:
>>
>>> 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
>>>
>>
>>
>>
>>  _______________________________________________
>> LLVM Developers mailing listLLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110804/e6e5b8af/attachment.html>