similar to: [LLVMdev] DSNodes for main() neither complete nor global?

Thanks for all your help so far. My problem is that what I have are the pool descriptors, which I by traversing the uses of poolinit and accessing the first argument of each call. I need to find the DSNode (in the original function) to which this pool descriptor corresponds. The rub is that this pool descriptor of course does not exist except in the clone. If I call getFuncInfo(), I get a

I figure (hopefully correctly) that I can iterate over all pool descriptors in a program by iterating over all users of poolinit and looking at the first argument. However, once I have a pool descriptor, I need to get its corresponding DSNode in the function in which it is complete (or in the global graph if it is a global). How do I do this? Thanks, --Patrick

Andrew Lenharth wrote: > On Fri, Aug 7, 2009 at 4:45 PM, Patrick Alexander > Simmons<simmon12 at cs.uiuc.edu> wrote: > >> I'm iterating over all LoadInst and StoreInst-type Instructions in a >> Function, and getNodeForValue() is sometimes returning NULL. Why is >> this happening? Shouldn't every load from or store to memory correspond >> to some

Harmen, your suggestion of inverting the mapping almost worked (and Andrew was correct that the function I need is the same as the one in which poolinit appears). Unfortunately, it appears that this mapping only considers the original function and not any of its clones. Since the pool descriptor in question may very well only exist in a clone, I can't use this. Is there another way?

Hi Patrick, That's right. DSNodes are coupled to the original function. For function clones, you first need to get the original function, and then use the DSNode from that function. FuncInfo contains the information if a function is a clone and what the original function is. If you want to find the corresponding DSNode for some instruction, you must call PA::FuncInfo::MapValueToOriginal(

You might want to have a look at PoolAllocate.h. Per function, a PA::FuncInfo structure keeps track of all DSNodes that should be pool allocated. ArgNodes contains pool arguments, NodesToPA contains nodes that are locally pool allocated and thus initialized using poolinit. PoolDescriptors contains a mapping from DSNodes to pool descriptors, and you could easily invert this mapping. Finding a

On 03/19/10 08:56, John Criswell wrote: > Patrick Simmons wrote: >> Thanks for all your help so far. >> >> My problem is that what I have are the pool descriptors, which I by >> traversing the uses of poolinit and accessing the first argument of >> each call. I need to find the DSNode (in the original function) to >> which this pool descriptor

Patrick Simmons wrote: > Thanks for all your help so far. > > My problem is that what I have are the pool descriptors, which I by > traversing the uses of poolinit and accessing the first argument of each > call. I need to find the DSNode (in the original function) to which > this pool descriptor corresponds. The rub is that this pool descriptor > of course does not

I'm iterating over all LoadInst and StoreInst-type Instructions in a Function, and getNodeForValue() is sometimes returning NULL. Why is this happening? Shouldn't every load from or store to memory correspond to some DSNode? --Patrick

On Fri, Aug 7, 2009 at 4:45 PM, Patrick Alexander Simmons<simmon12 at cs.uiuc.edu> wrote: > I'm iterating over all LoadInst and StoreInst-type Instructions in a > Function, and getNodeForValue() is sometimes returning NULL.  Why is > this happening?  Shouldn't every load from or store to memory correspond > to some DSNode? Not if the pointer is null or the pointer

On Tue, Mar 16, 2010 at 3:46 PM, Patrick Alexander Simmons <simmon12 at cs.uiuc.edu> wrote: > I figure (hopefully correctly) that I can iterate over all pool > descriptors in a program by iterating over all users of poolinit and > looking at the first argument.  However, once I have a pool descriptor, > I need to get its corresponding DSNode in the function in which it is >

Depending on the value of dsa_pass_to_use, either EquivBUDataStructures or EQTDDataStructures is used. In the case that the top-down DSA is used, information is pushed down to nodes in callees. However, if bottom-up DSA is used, information has only been merged upwards and the nodes are not necessarily equivalent. Harmen Andrew Lenharth wrote: > On Tue, Mar 16, 2010 at 3:46 PM, Patrick

John Criswell wrote: > You can sometimes get NULL DSNodes if a previously-run transform pass > adds pointers to the program but doesn't update DSA while claiming to > preserve it. The pool allocation pass, for example, does this: it > claims to preserve the DSA results (when used for SAFECode) but doesn't > properly update the DSGraph when it adds pool handles. Therefore,

Patrick Alexander Simmons wrote: > Andrew Lenharth wrote: > >> On Fri, Aug 7, 2009 at 4:45 PM, Patrick Alexander >> Simmons<simmon12 at cs.uiuc.edu> wrote: >> >> >>> I'm iterating over all LoadInst and StoreInst-type Instructions in a >>> Function, and getNodeForValue() is sometimes returning NULL. Why is >>> this

Patrick Alexander Simmons wrote: > John Criswell wrote: > >> You can sometimes get NULL DSNodes if a previously-run transform pass >> adds pointers to the program but doesn't update DSA while claiming to >> preserve it. The pool allocation pass, for example, does this: it >> claims to preserve the DSA results (when used for SAFECode) but doesn't >>

Is there some efficient way to find the malloc instructions which point to the memory represented by a DSNode? Right now the only way I see is by iterating through the value map in the DSGraph object and finding every value that points to my DSNode. A possibly related question: is there a way to tell that the node has been merged, and if so, what types of nodes went into the merge? Thanks,

Chris Lattner wrote: > > Is there some efficient way to find the malloc instructions which point > > to the memory represented by a DSNode? Right now the only way I see is > > by iterating through the value map in the DSGraph object and finding > > every value that points to my DSNode. > > You're right, you have to iterate over the program, looking to see what

Thank you, and I apologize for conflating the two passes. My main remaining concern is about what happens when there is a node in a function's DSGraph that points to a pool (or pools, if there are multiple callers) that is not in the DSGraph of that function. For example, on page 3 of the 2005 PLDI paper, the DSGraph given for createnode(), Data is pointing to an unlabeled node in the

On 12/16/16 9:53 PM, 杨至轩(Zhixuan Yang) via llvm-dev wrote: > Hello, everyone! > > I'm writing an automatic memory leak fixing tool recently. For my > task, I'm using the DSA (Data Structure Analysis) for alias analysis. > In my task, when I detect a memory leak, I need to find a pointer (in > C) 'must-alias' with the corresponding resource. If I understand

Hello, everyone! I'm writing an automatic memory leak fixing tool recently. For my task, I'm using the DSA (Data Structure Analysis) for alias analysis. In my task, when I detect a memory leak, I need to find a pointer (in C) 'must-alias' with the corresponding resource. In DSA, I think if two Value* point to the same DSNode, they 'may-alias'. If two Value* point to