similar to: [LLVMdev] DSA: AuxFunctionCall

On Tue, Jul 21, 2009 at 10:58 PM, Patrick Simmons<simmon12 at illinois.edu> wrote: > What is this used for?  Does DSA put anything here?  If I want to add > call sites here during my pass, will it confuse pool allocation if it > runs afterwards?  If so, is there any way I could clear it at the end of > my pass? This is used for unprocessed callsites. Clearing it between DSA

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

Okay, are C standard library functions typically external in a fully linked LLVM bytecode file? --Patrick Andrew Lenharth wrote: > If the function is external, then DSA won't create a graph for it. > > Andrew > > On Mon, Jul 13, 2009 at 4:54 PM, Patrick Alexander > Simmons<simmon12 at cs.uiuc.edu> wrote: > >> I'm noticing that DSA graphs are not

I'm noticing that DSA graphs are not created for library functions like "puts". The bytecode file runs with lli, so I think I did my linking okay. Is this normal, or does it mean I'm somehow not giving the algorithm the complete program information it needs? 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

Hi, I'm trying to run the pool allocation pass through opt, and I'm running into problems. It segfaults frequently; for example, it does this when the input is a simple Hello World program: [simmon12 at apoc testcases]$ opt -load /home/vadve/simmon12/llvm/llvm/projects/llvm-poolalloc/Debug/lib/libLLVMDataStructure.so -load

If the function is external, then DSA won't create a graph for it. Andrew On Mon, Jul 13, 2009 at 4:54 PM, Patrick Alexander Simmons<simmon12 at cs.uiuc.edu> wrote: > I'm noticing that DSA graphs are not created for library functions like > "puts".  The bytecode file runs with lli, so I think I did my linking > okay.  Is this normal, or does it mean I'm

I've been attempting to write my pass (which depends on DSA and pool allocation) against the SVN trunk of LLVM and the llvm-poolalloc project. However, I was thinking it might be better to use the latest stable releases of these codebases. I know that this is the 2.5 branch for LLVM, but are there any stable releases of pool allocation? If so, would there be any disadvantage to my

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

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 >

Andrew Lenharth wrote: > If I remember correctly, it only tries to resolve indirect calls. The > analysis doesn't track direct calls because you can do it just as well > yourself. DSCallGraph::callee_begin() and DSCallGraph::callee_end() cooperate to iterate over an empty set (EmptyActual) for any call site not found in the ActualCallees map. So if direct calls are not tracked,

Hi, I ran into a problem when running DSA on Linux kernel (the Kernel version I used is 2.4.31). The analysis was aborted when it tried to do DSNode::mergeTypeInfo on some data structure in the kernel. I have filed a bug report at http://llvm.org/bugs/show_bug.cgi?id=1656. My question is what version of Linux kernel LLVM has been tested on successfully? To run DSA analysis, should I use the

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 updated the latest "poolalloc" code and the problem seems to have been fixed. However, I am still having problem of running "poolalloc". After compilation finished, there are several dynamic libraries created (libpoolalloc_rt.so, libpoolalloc_fl_rt.so and LLVMDataStructure.so). I was not sure which one I should use so I just tried all of them with "opt -load".

I don't really have a specific question, but, as I've been looking through pool allocation and the DS graphs extensively, I wanted to verify that my understanding of the representations used is correct. Therefore, I'm summarizing my understanding below (which, if it's correct, may hopefully be helpful to others). I would appreciate if someone who understands pool allocation

DSA should be current against head, but poolalloc isn't. I've changed DSA a bit so it may not compile with poolalloc as is. I haven't had time to tackle updating poolalloc (either to head or to the dsa changes). If you want the version from the paper, try checking out llvm 1.8 or 1.9 and a dsa from around then. The dsa as used on the linux kernel and in the OS work is in a branch

Torvald Riegel wrote: > On Thursday 11 June 2009 18:14:08 John Criswell wrote: > >> If your use of pool allocation requires that you can always get the pool >> handle for a pointer, you need to make sure that pool allocation is >> configured so that it doesn't generate the above scenario. I think >> there is an option to make all pools be global pools.

Haifeng He wrote: > I updated the latest "poolalloc" code and the problem seems to have been fixed. > However, I am still having problem of running "poolalloc". > > After compilation finished, there are several dynamic libraries > created (libpoolalloc_rt.so, libpoolalloc_fl_rt.so and > LLVMDataStructure.so). I was not sure which one I should use so I just