llvm dev - Jul 2016 - [LLVMdev] Interprocedural use-def chains

Hello,

I have been using the USE class to access the use-def chains of different
values. However, what I have noticed is that the set of users of a
particular value is limited for the appearance of that variable in the
current function.

How can I get the interprocedural use of a particular value? For example,
if a variable *a* is used as an argument in a function call *foo*, the USE
analysis would go to the definition of* foo*, and get me the users of that
argument in the called function as well. Currently, what USE does is that
it returns the call as a use and stops there.

Any information or ideas would be appreciated.

-- 
Dounia KHALDI
Research Assistant Professor
Institute for Advanced Computational Science
Stony Brook University
Stony Brook, NY 11794-5250
www.iacs.stonybrook.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160726/40900586/attachment.html>

Hi Dounia,

Dounia Khaldi via llvm-dev wrote:
 > I have been using the USE class to access the use-def chains of
 > different values. However, what I have noticed is that the set of users
 > of a particular value is limited for the appearance of that variable in
 > the current function.
 >
 > How can I get the interprocedural use of a particular value? For
 > example, if a variable /a/ is used as an argument in a function call
 > /foo/, the USE analysis would go to the definition of/foo/, and get me
 > the users of that argument in the called function as well. Currently,
 > what USE does is that it returns the call as a use and stops there.

Why not just recurse to uses of the corresponding llvm::Argument
instance?  Is there a reason why you're avoiding that?  This won't
work for varargs, but that's a difficult problem anyway.

Specifically, I'm saying:

   if (user is CallInst or InvokeInst) {
     unsigned ArgNo = // Get argument no. of Use &
     if (auto *F = getCallTargetIfPossible()) {
       pushToWorklist(F->getArgument(ArgNo)->users()); // Or recurse
     }
   }

-- Sanjoy

Thanks for your reply.

Yes, I was about to recurse over the use list of the argument in the called
function. I did not want to pursue that because with this solution, I am
going to implement the interprocedural part myself and was wondering if
that was not already done. I was not also 100% sure that this will work for
any type of arguments.

If, based on your response, this is my only solution then I will go for it.

Thanks,
Dounia


On Tue, Jul 26, 2016 at 5:51 PM, Sanjoy Das <sanjoy at
playingwithpointers.com>
wrote:
> Hi Dounia,
>
> Dounia Khaldi via llvm-dev wrote:
> > I have been using the USE class to access the use-def chains of
> > different values. However, what I have noticed is that the set of
users
> > of a particular value is limited for the appearance of that variable
in
> > the current function.
> >
> > How can I get the interprocedural use of a particular value? For
> > example, if a variable /a/ is used as an argument in a function call
> > /foo/, the USE analysis would go to the definition of/foo/, and get me
> > the users of that argument in the called function as well. Currently,
> > what USE does is that it returns the call as a use and stops there.
>
> Why not just recurse to uses of the corresponding llvm::Argument
> instance?  Is there a reason why you're avoiding that?  This won't
> work for varargs, but that's a difficult problem anyway.
>
> Specifically, I'm saying:
>
>   if (user is CallInst or InvokeInst) {
>     unsigned ArgNo = // Get argument no. of Use &
>     if (auto *F = getCallTargetIfPossible()) {
>       pushToWorklist(F->getArgument(ArgNo)->users()); // Or recurse
>     }
>   }
>
> -- Sanjoy
>


-- 
Dounia KHALDI
Research Assistant Professor
Institute for Advanced Computational Science
Stony Brook University
Stony Brook, NY 11794-5250
www.iacs.stonybrook.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160726/e33544a2/attachment.html>