similar to: [LLVMdev] Find mallocs from a DSNode

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

> 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 DSNodes the Malloc instructions point to. This is

We have created a new alias -- llvmbugs at cs.uiuc.edu. Please use this for reporting bugs or turning in patches for LLVM. Any such feedback would be appreciated! Please continue to use llvmdev to post questions or have discussions about LLVM. --Vikram http://www.cs.uiuc.edu/~vadve

I have some questions regarding how globals are represented in DS graph. Specifically, I wrote the following simple program: List *g; void alloc_func(){ g = ( List* ) malloc( sizeof( List ) ); } void free_func(){ free( g ); } int main(){ alloc_func(); free_func(); } I noticed that the DSnode for g in alloc_func is different from that of free_func and NEITHER of them had GlobalNode

Hi, Chris, I was wondering if you had a chance to look at this problem. Could you let me know how to decide if this is a heap node in this case? It's important because my code depends on this information. Thanks, Jerry On Thu, 21 Nov 2002, Chris Lattner wrote: > > When I use analyze to construct the DSGraph for the lists.c program in > > test/Programs/SingleSource/Shootout

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

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(

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?

Dear LLVM, When I use analyze to construct the DSGraph for the lists.c program in test/Programs/SingleSource/Shootout directory. I found out the heap node in the function test_list() all have type FOLDED:R. I was wondering why it's not heapnode anymore? My pass need to use this type information to determine whether a node is heap node. Is there any way I can know this is a heap node in this

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

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

> > When two nodes are merged, their Flags are bitwise or'd together... > > I realized that, but what if two nodes of the same type are merged? Their > flags will not indicate that a merge has occurred. I'm concerned about the > case where two malloc nodes are merged, because then if free is called on the > memory represented by that node, you cannot be certain of

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

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

Ganesh, I modified DataStructure.cpp so that global nodes are no longer removed from any graphs. Only that file has changed. Chris, if you get a chance to do this, it would be nice if you could take a quick look at the change I made and make sure that's all that's needed. Thanks, --Vikram http://www.cs.uiuc.edu/~vadve > From: Chris Lattner <sabre at nondot.org> >

Hello, I’m trying to port a project up to 4.0 and I’m seeing the following error: In file included from /Users/jaredcarlson/Projects/llvm-4.0.0.src/include/llvm/ADT/StringRef.h:13: /Users/jaredcarlson/Projects/llvm-4.0.0.src/include/llvm/ADT/STLExtras.h:139:13: error: no type named 'type' in 'std::__1::result_of<std::__1::pointer_to_unary_function<llvm::DSNode *, llvm::DSNode

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

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

I use the following code to do the depth first search on the DSGraph. And I always got this error message. Couldn't figure out what's wrong. Could you please let me know? Besides, I really have no idea about what those functions do. Is there any documentation about DSGraph functions besides the pool allocation paper? Thanks, xiaodong Code: for( df_iterator<DSNode*> I =