Hi, I want to get the information where the address of load/store comes from, like below load instruction, %152 may come from a getelementpr, or comes from some gep+ptrtoint+add+inttoptr... instructions. what's the recommended way to find the original memory pointer? %153 = load <2 x i16> addrspace(1)* %152, align 2 going through the use-def chain seems not easy, because the 'add' operation contains two operands, one come from a pointer, the other is an integer offset. I could not know which is at operand 0 and which is at operand 1. Thanks! Ruiling -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141119/419f63df/attachment.html>
Previously, I started from the load/store instructions, and tried to find the original definitions by going through defs recursively. And I met the problem described in last mail. It seems that I have to do things reversely. That is to start from definitions of pointers/memory objects and check their uses recursively. I don't know whether this is a good idea. Or is there any other good suggestion? Thanks! Ruiling 2014-11-19 16:54 GMT+08:00 Ruiling Song <ruiling.song83 at gmail.com>:> Hi, > > I want to get the information where the address of load/store comes from, > like below load instruction, %152 may come from a getelementpr, or comes > from some gep+ptrtoint+add+inttoptr... instructions. what's the recommended > way to find the original memory pointer? > > %153 = load <2 x i16> addrspace(1)* %152, align 2 > > going through the use-def chain seems not easy, because the 'add' > operation contains two operands, one come from a pointer, the other is an > integer offset. I could not know which is at operand 0 and which is at > operand 1. > > Thanks! > Ruiling > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141124/8f71232b/attachment.html>
John Criswell
2014-Nov-24 05:12 UTC
[LLVMdev] How to analyze where the address comes from?
On 11/19/14, 3:54 AM, Ruiling Song wrote:> Hi, > > I want to get the information where the address of load/store comes from, > like below load instruction, %152 may come from a getelementpr, or > comes from some gep+ptrtoint+add+inttoptr... instructions. what's the > recommended way to find the original memory pointer? > > %153 = load <2 x i16> addrspace(1)* %152, align 2 > > going through the use-def chain seems not easy, because the 'add' > operation contains two operands, one come from a pointer, the other is > an integer offset. I could not know which is at operand 0 and which is > at operand 1.To find the source of the pointer for the LoadInst, you'll need to climb up the def-use chain. In the case of an add instruction, you will have to search back through both operands to figure out which one originates from a pointer. You will also have to handle phi-nodes, so you'll probably need a list of processed phi-nodes to ensure that you don't iterate indefinitely. The only other way to do it is find all the definitions that you consider to be pointer "origins" (e.g., function arguments, the results of load instructions, etc.) and iterate through their uses until you find the load instruction that uses the pointer (in this case, %153). In other words, instead of starting at a use and searching for the definition, you start at all possible definitions and look for the use. If you're searching for a lot of pointers, this may end up being more efficient as you won't be traversing the same definitions over and over again. In short, you're attacking the problem in the right way, and I don't think there's really any better way of doing it. Regards, John Criswell> > Thanks! > Ruiling > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-- John Criswell Assistant Professor Department of Computer Science, University of Rochester http://www.cs.rochester.edu/u/criswell -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141124/e2d8fd2f/attachment.html>
Hi John, Thank you so much for the comments! I will do it as suggested. Thanks! Ruiling 2014-11-24 13:12 GMT+08:00 John Criswell <jtcriswel at gmail.com>:> On 11/19/14, 3:54 AM, Ruiling Song wrote: > > Hi, > > I want to get the information where the address of load/store comes > from, > like below load instruction, %152 may come from a getelementpr, or comes > from some gep+ptrtoint+add+inttoptr... instructions. what's the recommended > way to find the original memory pointer? > > %153 = load <2 x i16> addrspace(1)* %152, align 2 > > going through the use-def chain seems not easy, because the 'add' > operation contains two operands, one come from a pointer, the other is an > integer offset. I could not know which is at operand 0 and which is at > operand 1. > > > To find the source of the pointer for the LoadInst, you'll need to climb > up the def-use chain. In the case of an add instruction, you will have to > search back through both operands to figure out which one originates from a > pointer. You will also have to handle phi-nodes, so you'll probably need a > list of processed phi-nodes to ensure that you don't iterate indefinitely. > > The only other way to do it is find all the definitions that you consider > to be pointer "origins" (e.g., function arguments, the results of load > instructions, etc.) and iterate through their uses until you find the load > instruction that uses the pointer (in this case, %153). In other words, > instead of starting at a use and searching for the definition, you start at > all possible definitions and look for the use. If you're searching for a > lot of pointers, this may end up being more efficient as you won't be > traversing the same definitions over and over again. > > In short, you're attacking the problem in the right way, and I don't think > there's really any better way of doing it. > > Regards, > > John Criswell > > > > > Thanks! > Ruiling > > > > _______________________________________________ > LLVM Developers mailing listLLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > -- > John Criswell > Assistant Professor > Department of Computer Science, University of Rochesterhttp://www.cs.rochester.edu/u/criswell > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141125/adc168df/attachment.html>
To find the source of the pointer for the LoadInst, you'll need to climb up the def-use chain. In the case of an add instruction, you will have to search back through both operands to figure out which one originates from a pointer. You will also have to handle phi-nodes, so you'll probably need a list of processed phi-nodes to ensure that you don't iterate indefinitely. I tried the above idea, but I find it is easy find out whether a operand comes from a pointer. But for the other operand, which comes from a integer, it is hard to determine it does not come from a pointer, as integer may come from various kinds of instructions, the stop-condition to prevent further search is not obvious. As for the two operands of 'Add', i don't know which comes from pointer, obviously I have to go through both of them. I am not sure whether I understand your idea fully.> > The only other way to do it is find all the definitions that you consider > to be pointer "origins" (e.g., function arguments, the results of load > instructions, etc.) and iterate through their uses until you find the load > instruction that uses the pointer (in this case, %153). In other words, > instead of starting at a use and searching for the definition, you start at > all possible definitions and look for the use. If you're searching for a > lot of pointers, this may end up being more efficient as you won't be > traversing the same definitions over and over again. > > In short, you're attacking the problem in the right way, and I don't think > there's really any better way of doing it. > > Regards, > > John Criswell > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141127/c7f48fdb/attachment.html>