[LLVMdev] instruction/register identifier?

[Vikram S. Adve]

If I understand this right, you want to find the malloc that created the
object(s) being freed by a free instruction.  That requires alias
information, and you can do this using DS Graphs:

(1) To find matching mallocs in the same function:

	for each Instruction* I that is a malloc:
	   Check if I points to the same DS node as the argument of the
free

	Obviously this is expensive if you don't already know have a set
of mallocs to test.  You don't want to loop over all the instructions in
the procedure.

(2) To find matching mallocs in other functions:

       This is more work.  You have to match the DS Node pointed to by
the free to DS nodes in other functions and look for mallocs that point
to the corresponding DS node in other functions.

More generally, (if you really need to do this kind of search) I think
you should try to make it faster by keeping track of malloc instructions
for each DS Node in some appropriate data structure.

--Vikram
http://www.cs.uiuc.edu/~vadve


> -----Original Message-----
> From: llvmdev-admin at cs.uiuc.edu 
> [mailto:llvmdev-admin at cs.uiuc.edu] On Behalf Of Juan Nicolas Ruiz
> Sent: Wednesday, November 20, 2002 10:45 PM
> To: llvmdev at cs.uiuc.edu
> Subject: [LLVMdev] instruction/register identifier?
> 
> 
> Is there a way get the register on the LHS of a llvm 
> instruction? (in case there is one)
> 
> for example, given a "free %reg773", I want to find the 
> matching "%something = malloc %", where %something is not 
> necessarily %reg773. One way I found was to inmediately 
> follow the use-def chain up from the free to the malloc. But 
> instead, I want to put %reg773 in a set (possibly with many 
> other %things), and when I find "%something = malloc" look 
> for %something in the set. One way to do it (as far as I see) 
> is to store the "defs" in the set. But I was thinking about 
> storing only the "%reg" (the name, a unique identifier), but 
> I don't see how to get it from an Instruction.
> 
> I'm not sure the above explanation makes much sense. Too much 
> caffeine, I guess.
> 
> thanks in advance
> nicolas
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev
>