similar to: [LLVMdev] Fwd: Order of Basic Blocks

Is there a way to cast the rpo_iterator to a basic block pointer? I need to use the functions of the class Basic Block. On Sun, Nov 20, 2011 at 3:15 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Sorry, forgot to add group to CC. > > On Sun, Nov 20, 2011 at 6:14 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > >> Cameron, >> >> To make it less vague,

Sorry, forgot to add group to CC. On Sun, Nov 20, 2011 at 6:14 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Cameron, > > To make it less vague, I would ideally like to traverse top down. I > believe what you suggested is what I want, I will have a look at it. > > Currently, I am iterating over the BBs in a Function, so > Function::iterator BBitr=F->begin(),

On 08/05/2010 06:46 AM, Wenbin Zhang wrote: > Hi all, > I'm using postDominatorTree to do some program analysis. My code works > well for small tests, but when I run it on real applications, the > following error occurs: > /Inorder PostDominator Tree: DFSNumbers invalid: 0 slow queries. > [1] <<exit node>> {0,21} > [2] %bb1 {1,2} > [2] %bb {3,4} > [2]

Hi, It looks like PDT.getRootNode() returns NULL for: define fastcc void @c974001__lengthy_calculation. 1736(%struct.FRAME.c974001* nocapture %CHAIN.185) noreturn { entry: br label %bb bb: br label %bb } Isn't it a bug in PostDominatorTree? Please note that this crashes: opt -postdomtree -debug dom_crash.bc I think this should be reported as a bug, -Jakub On Sep 3, 2009, at

Jakub Staszak wrote: > Hi, > > It looks like PDT.getRootNode() returns NULL for: > > define fastcc void @c974001__lengthy_calculation. > 1736(%struct.FRAME.c974001* nocapture %CHAIN.185) noreturn { > entry: > br label %bb > > bb: > br label %bb > } > > > Isn't it a bug in PostDominatorTree? > > Please note that this crashes: >

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~ Best, --Wenbin ----- Original Message ----- From: "Tobias Grosser" <grosser at fim.uni-passau.de> To: "Wenbin Zhang" <zhangwen at cse.ohio-state.edu> Cc: <llvmdev at cs.uiuc.edu> Sent: Thursday, August

Hello, Bug is already fixed by Chris (see: http://llvm.org/bugs/show_bug.cgi?id=4915) . I added getRootNode() == NULL condition to my patch. It's not a great solution, but it is enough for now I think. New patch attached. -Jakub -------------- next part -------------- A non-text attachment was scrubbed... Name: dse_ssu-2.patch Type: application/octet-stream Size: 17762 bytes Desc: not

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 Quentin, I have rerun the test case on a recent commit, so the numbers have changed. There are also now a few more basic blocks very small basic blocks in the function, and therefore there are some slight differences. I tried to go back to earlier commits, without success for some reason... This is however very similar, except that there becomes two COPYs back to sibling value after the loop.

Hi Jonas, Thanks for your patience. After spending some time looking at the additional output you gave me, I agree that your fix is the right one. I was worried that this problem may arise because we were spilling not real user, but in fact what I thought was the problem is an optimization we could do :). See my comments inlined for a few nitpicks before you commit. Thanks again, -Quentin On

I have what appears to be a bug in LLVM... I'm deeply hesitant to label it a bug, given my lack of experience with LLVM, but the behaviour of this fragment strongly suggests a bug. In particular, compiling and running this fragment using a fresh SVN build yields this stderr: uccello:/tmp clements$ lli a.out.bc 0 lli 0x005e72b6 char const* std::find<char const*,

LLVMers, Is there any way to guarantee iteration of the basic blocks from top down or path to path? Currently it looks sort of semi-random, sometimes visiting loop heads first and other times loop tails, is there a way I can visit the BBs top down or path to path? Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi Haicheng, Originally I ran into this on our out-of-tree target but I managed to reproduce the crash on X86 as well now: build-all/bin/opt -S -sroa -loop-rotate -loop-deletion -licm -loop-idiom ../llvm/bugpoint-reduced-simplified.i8+.ll gives: While deleting: void % An asserting value handle still pointed to this value! UNREACHABLE executed at ../lib/IR/Value.cpp:696! 0 opt

> On Sep 21, 2016, at 2:23 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > > > > // For all predecessors of this MBB, find the set of VarLocs that > // can be joined. > for (auto p : MBB.predecessors()) { > auto OL = OutLocs.find(p); > // Join is null in case of empty OutLocs from any of the pred. > if (OL == OutLocs.end()) >

Hi Jakub, interesting patch. I ran it over the Ada testsuite and this picked up some problems even without enabling dse-ssu. For example, "opt -inline -dse -domtree" crashes on the attached testcase. Ciao, Duncan. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: dom_crash.ll URL:

Hello, This patch adds non-local DSE optimization. It uses Static Single Use representation. This is my first "big" patch, please be tolerant :-) Please note that optimization is disabled by default. -Jakub -------------- next part -------------- A non-text attachment was scrubbed... Name: dse_ssu.patch Type: application/octet-stream Size: 17352 bytes Desc: not available URL:

On Jun 8, 2009, at 2:42 PM, robert muth wrote: > On Sun, Jun 7, 2009 at 11:53 PM, Evan Cheng <evan.cheng at apple.com> > wrote: >> >> On Jun 7, 2009, at 6:59 AM, robert muth wrote: >> >>> On Sat, Jun 6, 2009 at 4:51 PM, Evan Cheng<evan.cheng at apple.com> >>> wrote: >>>> +cl::opt<std::string>

Hi all, I'm using postDominatorTree to do some program analysis. My code works well for small tests, but when I run it on real applications, the following error occurs: Inorder PostDominator Tree: DFSNumbers invalid: 0 slow queries. [1] <<exit node>> {0,21} [2] %bb1 {1,2} [2] %bb {3,4} [2] %entry {5,6} [2] %bb8 {7,20} [3] %bb7 {8,9} [3] %bb2 {10,11}

On Sun, Jun 7, 2009 at 11:53 PM, Evan Cheng <evan.cheng at apple.com> wrote: > > On Jun 7, 2009, at 6:59 AM, robert muth wrote: > >> On Sat, Jun 6, 2009 at 4:51 PM, Evan Cheng<evan.cheng at apple.com> >> wrote: >>> +cl::opt<std::string> FlagJumpTableSection("jumptable-section", >>> +                                          

Evan: Sorry for the late follow up, I was out of town last week. Enclosed please find the updated patch including all your suggestions and a dejagnus test. Robert On Thu, Jun 11, 2009 at 2:27 PM, Evan Cheng <evan.cheng at apple.com> wrote: > > On Jun 8, 2009, at 2:42 PM, robert muth wrote: > > > On Sun, Jun 7, 2009 at 11:53 PM, Evan Cheng <evan.cheng at apple.com>