similar to: [LLVMdev] va_arg

---------- Forwarded message ---------- From: Ryan Taylor <ryta1203 at gmail.com> Date: Mon, Nov 21, 2011 at 10:30 AM Subject: Re: [LLVMdev] Order of Basic Blocks To: Benjamin Kramer <benny.kra at googlemail.com> This worked, though the RPO_iterator apparently wasn't what I was looking for anyways, it seems it doesn't rreally go top->down. I have a simple example code,

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

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

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

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

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

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]

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

Provide a full-fledged example of working variable arguments on X86_64, since it's easily the most popular platform. Cc: Reid Kleckner <rnk at google.com> Signed-off-by: Ramkumar Ramachandra <artagnon at gmail.com> --- docs/LangRef.rst | 44 ++++++++++++++++++++++++++++++-------------- 1 file changed, 30 insertions(+), 14 deletions(-) diff --git a/docs/LangRef.rst

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}

I want to do the following: suppose the program structure: bb / \ bb1 bb2 \ / bb3

On Wed, Oct 1, 2008 at 1:19 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > LLVM seems to be generating way too complex of branching based on the > short-circuit optimization. The code in question is as follows: > > define void @ test_fc_while_and(float %x, float %y, float addrspace(11)* > %result) nounwind { > > entry: > > %tobool3 = fcmp une float

Hi, I want to insert a conditional branch in the middle of a basic block. To that end, I am doing these steps: (1) Split the basic block: bb->splitBasicBlock() (2) Remove the old terminator: succ->removePredecessor(bb) bb->getTerminator()->getParent() (3) Adding a new terminator: BranchInst::Create(ifTrue, ifFalse, cnd, "", bb); That seems to work, but later passes

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

I need to mark the beginning of some regions of code, that I want to patch at runtime. In this case, I want to mark the beginning of BB4 and then to patch the jumps, because I want to temporarily change the flow at runtime and then to restore the previous version. In order to patch, I need to know the exact structure of the generated code. So, I might have a BasicBlock like: BB4: call void asm

On Jun 24, 2010, at 7:00 AMPDT, Xinfinity wrote: > > I need to mark the beginning of some regions of code, that I want to > patch at > runtime. > In this case, I want to mark the beginning of BB4 and then to patch > the > jumps, because I want to temporarily change the flow at runtime and > then to > restore the previous version. > > In order to patch, I

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.

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>

On Jun 29, 2010, at 7:08 AM, ether zhhb wrote: > > why computeSCEVAtScope not try to get the operands in the current > scope like the function do with SCEVCommutativeExpr, like: > > if (const SCEVAddRecExpr *AddRec = dyn_cast<SCEVAddRecExpr>(V)) { > if (!L || !AddRec->getLoop()->contains(L)) { > ... > // Then, evaluate the AddRec. >