similar to: [LLVMdev] Pool Allocation and DSA

Patrick Alexander Simmons wrote: > 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

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

Patrick Alexander Simmons wrote: > 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

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

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

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 >>

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

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(

David Greene wrote: > On Monday 16 November 2009 13:04, John Criswell wrote: > >>> [snip] >>> >>> I applied the attached patch to make it compile on my box (Debian >>> x86_64), only to find out that x86_64 is not supported :( >>> This architecture is not supported by the pool allocator! >>> Aborted >>> >> Thanks

HI guys. I'm trying to build the poolalloc on llvm-2.0 but there exist some errors. Can you tell me which version of llvm is known to make the poolalloc build and install successful? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070710/4ab5e155/attachment.html>

On Monday 16 November 2009 14:18, John Criswell wrote: > > Did I miss a message? I am getting tons of compiler errors building > > poolalloc and safecode and am wondering if this patch would fix things. > > What platform are you building on? What types of errors are you > seeing? Edwin's patch will fix warnings for SAFECode on 64-bit platforms. I'm on a 64-bit

Hi all, I just ran into a strange problem. When using the Equivalence-class Bottom-up Data Structure Analysis pass and pool allocation, I noticed some objects using different pool descriptors where I expected them to be in the same pool. We use svn revision 66285 of the DSA. The following 2 programs expose the problem. First the version that runs correctly, ie. producing a single DSNode.

> ...... > DSGraph* DSG = getAnalysis<BUDataStructures>().getDSGraph( F ); > std::map< Value*, DSNodeHandle> scalarmap = DSG->getScalarMap(); > ...... > > The scalarmap is always empty. I printed the size of the map which came > out to be zero always. But the getNodeForValue works correctly for the > same DSG, which means that the scalarmap cannot be

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

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

Hi, I believe shouldHaveNodeForValue() should return false for ConstantPointerNullValue. Fixed in r121707. Arushi On Mon, Dec 13, 2010 at 12:10 PM, Kevin Streit <kevin.streit at googlemail.com>wrote: > I'm using BUDataStructures... But I tried LocalDatastructures and it didn't > work either... > On Dec 13, 2010 6:52 PM, "Arushi Aggarwal" <arushi987 at

> On 1/26/11 3:06 PM, songlh at cs.wisc.edu wrote: >>> [snip] >>> -- John T. >> Sorry, I am asking the second question. >> " >> how to determine, within an LLVM pass, what the >> possible target(s) of an indirect function call might be? > > There are at least two solutions. > > The first is to use the CallGraph analysis pass. It