similar to: [LLVMdev] getExitBlocks returns duplicates in result vector

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.

Hi, all. I'm using void LoopBase::getExitBlocks (SmallVectorImpl< BlockT * > &ExitBlocks) const to get all exit blocks for a loop. The problem I find with this API is that it returns repetitive basic blocks in certain situations. Should repetitive basic blocks be removed? I have an example to show the problem. Following is the source code and the CFG is enclosed. int main() { int

On Apr 19, 2012, at 10:43 PM, xiaoming gu <xiaoming.gu at gmail.com> wrote: > Hi, all. I'm using void LoopBase::getExitBlocks (SmallVectorImpl< BlockT * > &ExitBlocks) const to get all > exit blocks for a loop. The problem I find with this API is that it returns repetitive basic blocks in certain > situations. Should repetitive basic blocks be removed? Users

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

On Apr 23, 2012, at 10:31 PM, Andrew Trick <atrick at apple.com> wrote: > > On Apr 19, 2012, at 10:43 PM, xiaoming gu <xiaoming.gu at gmail.com> wrote: > >> Hi, all. I'm using void LoopBase::getExitBlocks (SmallVectorImpl< BlockT * > &ExitBlocks) const to get all >> exit blocks for a loop. The problem I find with this API is that it returns

hi, > Users generally expect a unique set of exit blocks, but don't make any > strong assumption. The worst that can happen is missed optimization or > redundant analysis. In most cases, the loop is in LoopSimplifyForm, so it's > probably not a problem in practice. > > > Another thing I should mention. The iteration order of ExitBlocks is > important. In llvm,

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, The poolalloc library fails in TransformFunctionBody.cpp, line 746 --- Value *ArgVal = ConstantAggregateZero::get(PoolAllocate::PoolDescPtrTy); --- opt -load /path_to_lib/libpoolalloc.dylib -poolalloc constaggr.bc -o opt.bc -f triggers the problem (bc file attached). Assertion failed: ((isa<StructType>(Ty) || isa<ArrayType>(Ty) || isa<VectorType>(Ty)) &&

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

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

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 all, On 2010-1-7 0:11, John Mosby wrote: > In LLVM we could add support for generalized CFG regions and > RegionPasses. A region is a part of the CFG. The only information we > have is, that it has one entry and one exit, this it can be optimized > separately. > I think this is the best way to add region analysis. I must admit > this approach > helps me on another,

On 01/08/10 14:20, ether wrote: > sorry that i forgot to change the subjuect Hi ether, sounds interesting. Actually is/may be some kind of region. If you want you can have a look at the analysis, that I wrote. It is not yet finished, not completely documented and work in progress. However the first big comment might be interesting for you. Or seeing the results of opt -regions -analyze

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

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

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

Why not use the "standard" algorithm for detecting SESE-regions and building a program structure tree? It should handle everything you want. It also becomes much simpler to specify a connected SESE-region by entry/exit edges, while a disconnected region is specified by entry/exit blocks. Only defining regions on blocks is not enough to be able to quickly determine how to replace/move a