search for: getblock

Hi all, I have a question about llvm::LoopBase getBlocks() method. Does it return the basic blocks inside the loop in random order? I need to order the blocks in some valid topological ordering of the AST. If getBlocks() does not do that, what can I do to find the ordering? Thanks, Naznin -------------- next part -------------- An HTML attachment was...

...hindsight, I don't even know if Function guarantees that they are presented in a topological order, but it always happened to be the case for me. On Mon, May 9, 2011 at 10:45 AM, Naznin Fauzia <laboni14 at gmail.com> wrote: > Hi all, > > I have a question about llvm::LoopBase  getBlocks() method. Does it return > the basic blocks inside the loop in random order? I need to order the blocks > in some valid topological ordering of the AST. If getBlocks() does not do > that,  what can I do to find the ordering? > > Thanks, > Naznin > > ________________________...

...unction guarantees that > they are presented in a topological order, but it always happened to > be the case for me. > > > On Mon, May 9, 2011 at 10:45 AM, Naznin Fauzia <laboni14 at gmail.com> wrote: > > Hi all, > > > > I have a question about llvm::LoopBase getBlocks() method. Does it > return > > the basic blocks inside the loop in random order? I need to order the > blocks > > in some valid topological ordering of the AST. If getBlocks() does not do > > that, what can I do to find the ordering? > > > > Thanks, > > N...

On 13:05 Tue 27 Mar , Apollon Oikonomopoulos wrote: > On 11:31 Tue 27 Mar , Apollon Oikonomopoulos wrote: > It turns out there's a missing byte-inversion when loading the blocks > which should be addressed in getblock{32,64}. Murmurhash treats each > block as an integer expecting little-endian storage. Applying this > additional change fixes the build on s390x (and does not break it on > x864_64): > > --- b/src/lib/murmurhash3.c > +++ b/src/lib/murmurhash3.c > @@ -23,7 +23,7 @@ > &gt...

...of LLVM, I believe you could get some sort of Node > object from DominatorTree and then use a method to get the children of > the Node There is a iterator that can be used to walk children. > (and then use a method of the Node to get the BasicBlock held > in that Node). This exists. getBlock(). - Devang

Hi, On 12:55 Mon 26 Mar , Josef 'Jeff' Sipek wrote: > On Mon, Mar 26, 2018 at 15:57:01 +0300, Apollon Oikonomopoulos wrote: > ... > > I'd be happy to test the patch, thanks! > > Ok, try the attached patch. (It is a first pass at the issue, so it may not > be the final diff that'll end up getting committed. It'd be good to know if > it actually

Wenbin Zhang wrote: > I'll try the trunk, as well as check my code again. If indeed it's not > fixed, I'll try to post a triggering case here. > Thanks for the advice~ > Did you run the -mergereturn pass (it might also be called UnifyExitNodes in the source code)? This is the pass that ensures that each function has exactly one basic block that returns control to the

Hi, I have some troubles to figure out why clang is removing my label name. As the simple example below shows the label "MLB" is removed and replaced by an integer as an "unnamed value". Plus, I can see that an unconditional jump is added, as the label seems to be interpreted as the beginning of a BasicBlock. I am compiling without any optimizations (for now), what leave the

Hi Piotr, On March 31, 2017 at 1:07:12 PM, Piotr Padlewski (piotr.padlewski at gmail.com) wrote: > [snip] > Do I understand it correctly, that it is legal to do the hoist because all > of the instructions above %vtable does not throw? Yes, I think you're right.  HeaderMayThrow is a conservative approximation, and the conservativeness is biting us here. > Are there any plans to

...rator<NodeTy>::operator--() [with NodeTy = llvm::Instruction]: Assertion `NodePtr && "--'d off the beginning of an ilist!"' failed. *LICM::HOistRegion(DomTreeNode *N)* { assert(N != 0 && "Null dominator tree node?"); BasicBlock *BB = N->getBlock(); ... * for (BasicBlock::iterator II = BB->end(); II != BB->begin(); ) *{ Instruction &I = *--II; if (isLoopInvariantInst(I) && canSinkOrHoistInst(I) && isSafeToExecuteUnconditionally(I)) * ho...

Hi, Can anyone tell me how to traverse Dominator tree in pre-order manner? Regards, Chayan

Chayan Sarkar wrote: > Hi, > > Can anyone tell me how to traverse Dominator tree in pre-order manner? > In previous versions of LLVM, I believe you could get some sort of Node object from DominatorTree and then use a method to get the children of the Node (and then use a method of the Node to get the BasicBlock held in that Node). However, I don't see such a method in the

I am writing an LLVM pass, where in certain cases, I want to know all the basic blocks in a loop. I can get the loop header by using combination of AU.addRequired < LoopInfo >( ); and getAnalysis < LoopInfo > ( *F ).isLoopHeader( BB ) But how do I get to know every basic block in that loop. -------------- next part -------------- An HTML attachment was scrubbed... URL:

...FAILED > test-murmurhash3.c:34: Assert(#12) failed: memcmp(result, vectors[i].result, sizeof(result)) == 0 > murmurhash3 (murmurhash3_128) ........................................ : FAILED It turns out there's a missing byte-inversion when loading the blocks which should be addressed in getblock{32,64}. Murmurhash treats each block as an integer expecting little-endian storage. Applying this additional change fixes the build on s390x (and does not break it on x864_64): --- b/src/lib/murmurhash3.c +++ b/src/lib/murmurhash3.c @@ -23,7 +23,7 @@ static inline uint32_t getblock32(const ui...

...at 13:15:31 +0300, Apollon Oikonomopoulos wrote: > On 13:05 Tue 27 Mar , Apollon Oikonomopoulos wrote: > > On 11:31 Tue 27 Mar , Apollon Oikonomopoulos wrote: > > It turns out there's a missing byte-inversion when loading the blocks > > which should be addressed in getblock{32,64}. Murmurhash treats each > > block as an integer expecting little-endian storage. Applying this > > additional change fixes the build on s390x (and does not break it on > > x864_64): > > > > --- b/src/lib/murmurhash3.c > > +++ b/src/lib/murmurhash3.c &g...

...pollon Oikonomopoulos wrote: > > On 13:05 Tue 27 Mar , Apollon Oikonomopoulos wrote: > > > On 11:31 Tue 27 Mar , Apollon Oikonomopoulos wrote: > > > It turns out there's a missing byte-inversion when loading the blocks > > > which should be addressed in getblock{32,64}. Murmurhash treats each > > > block as an integer expecting little-endian storage. Applying this > > > additional change fixes the build on s390x (and does not break it on > > > x864_64): > > > > > > --- b/src/lib/murmurhash3.c > > >...

.../lib/Transforms/ThreadBufferOptimizer/ThreadBufferOptimizer.h:20: In file included from /Developer/llvm/include/llvm/Analysis/PostDominators.h:17: /Developer/llvm/include/llvm/Analysis/Dominators.h:158:5: error: use of undeclared identifier 'WriteAsOperand' WriteAsOperand(o, Node->getBlock(), false); ^ /Developer/llvm/include/llvm/Analysis/Dominators.h:170:41: note: in instantiation of function template specialization 'llvm::operator<<<llvm::CallGraphNode>' requested here o.indent(2*Lev) << "[" << Lev << "] " <<...

...also took this opportunity to improve developer documentation. With this change you should see full stack traces from plugins, eg: ==2441== 32,768 bytes in 2 blocks are possibly lost in loss record 73 of 78 ==2441== at 0x4C2EBAB: malloc (vg_replace_malloc.c:299) ==2441== by 0x7928C79: GetBlocks (tclThreadAlloc.c:1044) ==2441== by 0x7928C79: TclpAlloc (tclThreadAlloc.c:358) ==2441== by 0x7928FEE: TclpRealloc (tclThreadAlloc.c:514) ==2441== by 0x784662B: Tcl_Realloc (tclCkalloc.c:1145) ==2441== by 0x79329BA: Tcl_DStringSetLength (tclUtil.c:2819) ==2441== by 0x78BFA...

Hi, I'm trying to solve a problem from StructurizeCFG not actually handling regions with multiple exits. Sample IR attached. StructurizeCFG doesn't touch this function, exiting early on the isTopLevelRegion check. SIAnnotateControlFlow then gets confused and ends up inserting an if into one of the blocks, and the matching end.cf into one of the return/unreachable blocks. The input to

....c index b2c52b3..b730010 100644 --- a/fs/ocfs2/aops.c +++ b/fs/ocfs2/aops.c @@ -90,7 +90,7 @@ static int ocfs2_symlink_get_block(struct inode *inode, sector_t iblock, iblock; buffer_cache_bh = sb_getblk(osb->sb, blkno); if (!buffer_cache_bh) { - mlog(ML_ERROR, "couldn't getblock for symlink!\n"); + mlog(ML_ERROR, "couldn't get block for symlink!\n"); goto bail; } @@ -191,7 +191,9 @@ static int ocfs2_get_block(struct inode *inode, sector_t iblock, (unsigned long long)iblock, (unsigned long long)p_blkno, (unsigned long...