similar to: [LLVMdev] Problem in CodeExtractor::severSplitPHINodes()

On Nov 19, 2008, at 7:41 AM, Jack Tzu-Han Hung wrote: > Hi, > > I found a problem in CodeExtractor::severSplitPHINodes() > <CodeExtractor.cpp>. > > The algorithm first separates the header block into two, one > containing only PHI nodes and the other containing the remaining non- > PHI nodes. The variable NewBB holds the pointer to the latter half > block.

Hi Devang, Thanks for your reply. But if you look at the comment of BasicBlock::splitBasicBlock(), it says that "...an unconditional branch is added to the new BB, and the rest of the instructions in the BB are moved to the newBB, including the old terminator." So, the terminator of the newBB is exactly the same as the terminator of the oldBB. IF the oldBB has multiple successors,

Hi folks, Hope this is not a silly question. But it bothers me when I am thinking about it. My question is: 1. In the implementation of serverSplitPHINodes(), why it only checks the first PHI node for possible multiple inputs from outside the region to extract. There could be more than one PHI nodes in the header block, and the code only checks the first one. I don't quite get it.

I'm having an issue with the CodeExtractor. When I try to extract the lone basic block from the following function, I get an assertion error. define i32 @test(i32 %x) { %tmp = call i32 @test3( i32 %x ) ; <i32> [#uses=1] ret i32 %tmp } The assertion error is: lli: Dominators.cpp:71: void llvm::DominatorTree::splitBlock(llvm::BasicBlock*): Assertion

Thanks for reply Chuck. Please excuse me if I'm not supposed to reply to all. Are you saying all PHI nodes are required to include all its predecessor blocks no matter they have input or not? What about successor blocks? Are they optional if they don't provide inputs? BTW, where should I look at to verify this, the mem2reg.cpp & PromoteMemToReg.cpp? Thanks a lot. On Sat, Mar 2, 2013

> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Wei Dang > Subject: [LLVMdev] Question about method CodeExtractor::severSplitPHINodes > In the implementation of serverSplitPHINodes(), why it only checks the > first PHI node for possible multiple inputs from outside the region to > extract. There could be more than one PHI nodes in

> From: Wei Dang [mailto:jacdang at gmail.com] > Subject: Re: [LLVMdev] Question about method CodeExtractor::severSplitPHINodes > Please excuse me if I'm not supposed to reply to all. You should do reply-all, to make sure the list sees all of the thread. > Are you saying all PHI nodes are required to include all its predecessor blocks > no matter they have input or not?

There might be a misuse of DominatorTree::splitBasicBlock in CodeExtractor.cpp, line 145. Header is splited into two (OldPred->NewBB). Line 145 updates the dominator tree by calling DT->splitBasicBlock(NewBB). I think it should be DT->splitBasicBlock(OldPred). When I tried to extract a code region whose header has 2 successors, my pass crashed. It was because header (or OldPred) is the

On Dec 31, 2010, at 11:20 AM, Vu Le wrote: > There might be a misuse of DominatorTree::splitBasicBlock in CodeExtractor.cpp, line 145. > Header is splited into two (OldPred->NewBB). > > Line 145 updates the dominator tree by calling DT->splitBasicBlock(NewBB). > I think it should be DT->splitBasicBlock(OldPred). > > When I tried to extract a code region whose

Hello, The CodeExtractor contains a std::set<BasicBlock*> to keep track of the blocks to extract. Iterators on this set are not deterministic, and so the functions that are generated are not (the order of the inputs/outputs can change). The attached patch uses a SetVector instead. Ok to apply ? Thanks, Julien -- Julien Lerouge PGP Key Id: 0xB1964A62 PGP Fingerprint: 392D 4BAD DB8B CE7F

I forgot to cc llvmdev. Here is my original message. I'm a bit confused on DominatorTreeBase::Split() ( http://llvm.org/docs/doxygen/html/Dominators_8h_source.html#l00229) If a basic block A splits into A->B, when I call Split(), which is NewBB? A or B? The semantics shows that NewBB is the newly split basic block B. But the assertion at line 229 doesn't seem right. 00229

(Resending after removing llvmdev at cs.uiuc.edu and using llvm-dev at lists.llvm.org) On Mon, Dec 7, 2015 at 3:08 PM, Easwaran Raman <eraman at google.com> wrote: > Hi Philip, > > Is there any update on this? I've been sending patches to get rid of the > callee hotness based inline hints from the frontend and move the logic to > the inliner. The next step is to use

On Thu, Dec 10, 2015 at 4:00 PM, Philip Reames <listmail at philipreames.com> wrote: > Given I didn't get any response to my original query, I chose not to invest > time in this at the time. I am unlikely to get time for this in the near > future. > > On 12/07/2015 03:13 PM, Easwaran Raman wrote: > > (Resending after removing llvmdev at cs.uiuc.edu and using >

In Dominators.h, the splitBlock(NewBB) method assumes that the NewBB has only one successor. I don't see why it cant have more than one successors. Is there a reason? Or it's just assumed that way to simplify things? Thanks a lot. -- Wei Dang -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Thu, Dec 10, 2015 at 4:51 PM, Philip Reames <listmail at philipreames.com> wrote: > > > On 12/10/2015 04:29 PM, Xinliang David Li wrote: >> >> On Thu, Dec 10, 2015 at 4:00 PM, Philip Reames >> <listmail at philipreames.com> wrote: >>> >>> Given I didn't get any response to my original query, I chose not to >>> invest

Hi Fellows, I am writing a pass that requires the DominatorTree pass. In the runOnFunction of my own pass, I call llvm::SplitBlock to split a block (%for.end) at it's first insert point. Then, when I dump my dominator tree immediately after, I can see the newly split %for.end.split, but its DFSNumIn and DFSNumOut are not properly updated in llvm::SplitBlock (i.e., still the initialized

Hi Andrew, Thanks a lot. But the function "DT->dominate(A,B)" decides the dominance relationship through comparing the DFS numbers, right? At least, in my example, when I check whether the newly split node (i.e., % *for.end.split*) DOMINATES the original node (I.e., %for.end), the answer is true, which is obviously wrong. Paul On Fri, Feb 14, 2014 at 1:59 AM, Andrew Trick

On Jan 8, 2010, at 5:01 PM, Julien Lerouge wrote: > Hello, > > The CodeExtractor contains a std::set<BasicBlock*> to keep track of > the > blocks to extract. Iterators on this set are not deterministic, and so > the functions that are generated are not (the order of the > inputs/outputs can change). > > The attached patch uses a SetVector instead. Ok to apply ?

Hi All, I’m currently working on a simple task which needs to transform loops into tail-recursive functions. I found the CodeExtractor class a handy helper to use, but later encountered a problem. Consider the following CU struct S { int a, b; }; int foo(struct S *s, unsigned n) {   struct S *next = s;   unsigned i;   for (i = 0; i < n; ++i) {     if (!s[i].a)      

I am working on a pass to extract small regions of code to run somewhere else (different node in a cluster). Basically what I need is the ability to isolate a region of code, get its inputs and outputs, create a new function with the extracted code and code aggregating the in and out parameters as structs that can be cast for a “void*”-based interface. It looks like the CodeExtractor