similar to: [LLVMdev] [PATCH] Fix nondeterministic behaviour in the CodeExtractor

On Fri, Jan 08, 2010 at 05:04:17PM -0800, Chris Lattner wrote: > 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 >

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 ?

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

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

On Oct 20, 2010, at 4:05 AM, Luke Dalessandro wrote: > If I register DemoteRegisterToMemoryID first I'd expect this to work. > then I get this assert during code extraction. > > CodeExtractor.cpp:681: llvm::Function*<unnamed>::CodeExtractor::ExtractCodeRegion(const std::vector<llvm::BasicBlock*, std::allocator<llvm::BasicBlock*> >&): Assertion

I have a transformation where I'd like to use both DominatorTree (for ExtractCodeRegion), and DemoteRegisterToMemory (i.e., reg2mem). The transformation is phased, so all occurrences of getAnalysis<DominatorTree>(Function) happen before any occurrence of getAnalysisID<FunctionPass>(&DemoteRegisterToMemoryID, Function). If I register these two passes with DominatorTree first, I

On 10/20/10 6:05 AM, Luke Dalessandro wrote: > I have a transformation where I'd like to use both DominatorTree (for ExtractCodeRegion), and DemoteRegisterToMemory (i.e., reg2mem). The transformation is phased, so all occurrences of getAnalysis<DominatorTree>(Function) happen before any occurrence of getAnalysisID<FunctionPass>(&DemoteRegisterToMemoryID, Function). I

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. Later, it tries to update DT information. if (DT) DT->splitBlock(NewBB); In splitBlock, it checks

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

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

On 18/11/13 21:43, Brandon Holt wrote: > 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

Hi Pablo, Your tool sounds really cool. It goes well beyond what I’m trying to do, which is really just extracting blocks of code, serializing and sending the inputs over to another core, running the code over there, and then sending the outputs back to the original caller (like an automatic RPC). So it sounds like most of the things your tool can do would be overkill for my use case. What I’ve

> 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

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

Hello folks, Just as a heads up, I chatted with Owen today about a little known bit of LLVM: lib/Transforms/Utils/CodeExtractor.cpp A toy project of mine has a use for this functionality, and it still seems to mostly work, so I'm going to be spending some time doing cleanup and general maintenance on the code to make it easier and more suitable for consumption by actual optimization passes.

Hello, I'm writing a pass using CodeExtractor to pull out a outmost loop as standalone function. But the 'Module Verifier' issues warning "function-local metadata used in wrong function". After looking through the CodeExtractor code, I found nothing about debugger intrinsics. Is this expected behavior? Thanks, yuanfang