similar to: [LLVMdev] Poolalloc asserts when passing in pool descriptors

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?

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

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(

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

On 10/11/2006 2:48 PM, Seth Falcon wrote: > Hi, > > Reading help("Documentation"), I'm led to believe that a help call > like: > > ?myFun(x, sqrt(wt)) > > Will search for help on the appropriate method in the case that myFun > is generic. This isn't working for me. Here is an example using the > Biobase package: > > ## If Biobase is

Hi, I compiled the poolalloc from SVN head. opt complains about missing symbol PoolAlloc::ID when I try to load libpoolalloc.so. Defining PoolAlloc::ID is not enough, since it is reused in PoolAllocPassAllPools. The append patch fixes the problem for me. Kind regards, Martin Index: include/poolalloc/PoolAllocate.h ===================================================================

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

Dear all, switch() called with just the EXPR argument causes R to hang so that the only way to stop it is to kill R. Reproducible example: > switch(EXPR="a") the internal C subroutine behind switch is do_switch located in R/src/main/builtin.c For convenience I reproduce it below. ***************************************************************************** SEXP attribute_hidden

plain text document attachment (lguest64-loader.patch) I noticed that the lguest loader code for i386 was in Documentation/lguest. Well, that's fine (I guess) but it can't just be for i386. So I made a separate directory to put the loader code in. So now we have: Documentation/lguest/i386/... for the lguest i386 loader. and Documentation/lguest/x86_64/... for the lguest x86_64

plain text document attachment (lguest64-loader.patch) I noticed that the lguest loader code for i386 was in Documentation/lguest. Well, that's fine (I guess) but it can't just be for i386. So I made a separate directory to put the loader code in. So now we have: Documentation/lguest/i386/... for the lguest i386 loader. and Documentation/lguest/x86_64/... for the lguest x86_64

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

Hi, As far as I understand now, only stack variables can be marked as gc roots. Our compiler however can also generate roots that are not necessarily on the stack. We can solve this by putting it on the stack anyway. So far so good. The problem is that we want to implement some sort of copying garbage collector. In this case, the roots on the stack must be updated. However, if this root

Hi, Learning the ropes of LLVM. I have this simple LLVM assembly snippet which compiles/runs fine in Ubuntu but won't work on snow leopard. Somehow related to 64-bit? Anyone else experience this? llvm-as if.ll llc -f if.bc gcc -o if if.s ld: 32-bit pointer out of range in _main from /var/folders/TY/TYHT2tSJEcaVdUEWeuX5P++++TI/-Tmp-//cck44HlB.o collect2: ld returned 1 exit status --------

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.

It runs fine on my Snow Leopard installation. I do recall though that LLVM did not build in 64-bit mode automatically. I configured LLVM as follows to get a 64-bit build. ./configure --build=x86_64-apple-darwin10 --host=x86_64-apple-darwin10 --target=x86_64-apple-darwin1 Harmen Tommy Chheng wrote: > Hi, > Learning the ropes of LLVM. I have this simple LLVM assembly snippet > which

I'm trying to turn some GenericValues into Constants in the interpreter using code like this, in a switch statement: case Type::IntTyID: SI = ConstantSInt::get(FB->getType(), ArgVals[i].IntVal); params.push_back(UI); UI->dump(); //for testing break; FB is a Function::ArgumentListType::iterator ArgVals is a std::vector<GenericValue> the switch

On 2009-03-20, at 05:09, Harmen van der Spek wrote: > The problem is that we want to implement some sort of copying > garbage collector. In this case, the roots on the stack must be > updated. However, if this root is also stored in an IR register, > then this pointer should be updated as well. Is there support for > identifying and updating such references in the GC

Hi, LoopBase::getExitBlocks in LoopInfo.h returns all exit basic blocks by iterating over all blocks of a loop and storing all branch targets that are outside the loop. This method allows for duplicates in the result vector, e.g.: Loop at depth 2 containing: %bb2<header><exit>,%bb1<latch>,%bb3<exit> where both bb2 and bb3 have bb4 as their exit block. This loop

Hello R-devel, Currently on Unix-like systems, Sys.which incorporates the absolute path to the `which` executable, obtained at the configure stage: > ## hopefully configure found [/usr]/bin/which > which <- "@WHICH@" > if (!nzchar(which)) { > warning("'which' was not found on this platform") This poses a problem for the Spack package