similar to: [LLVMdev] Splitting a basic block, replacing it's terminator

On May 8, 2009, at 4:02 PM, Nick Johnson wrote: > 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() Assuming that the new block will still be a

Hi, The 'br' instruction has the syntax: br i1 <cond>, label <iftrue>, label <iffalse> br label <dest> ; Unconditional branch If we know <cond>'s type must be 'i1', <iftrue><iffalse><dest> have to be of type 'label', why does the syntax have to specify them?

Hello, All, Mac OS 10.6.5 R64 2.11.1 This works as expected: f1 = c(0.084, 0.099, 0) data= data.frame(f1) data$f1=with(data,ifelse(f1==0, 0.0001, f1)) data f1 1 0.0840 2 0.0990 3 0.0001 Substituting ''f1==0'' with ''T'' produces the expected result: f1 = c(0.084, 0.099, 0) data= data.frame(f1) data$f1=with(data,ifelse(T, 0.0001, f1)) data f1 1 1e-04

John, Thanks for the reply. I agree with your comments that the "Memory" LLVM Spec refers to doesn't include stack. Let me leverage a bit further: If I need to work on high-level IRs (not machine dependent, not in the code-gen stage), is it reasonable to assume that ALL LLVM IRs that have a result field will have potential to write stack? E.g. <result> =

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 Dean, Thanks for your reply. That's exactly what I am doing, but I was looking for a default optimization or pass implementation if there was. I used BasicBlock::splitBasicBlock() but it puts "br" end of original basic block. I tried to delete the br instruction by using eraseFromParent() but it didn't work. I had to rewrite my own splitBasicBlock() by modifying the

Hi, On Mon, May 1, 2017 at 8:47 AM, Daniel Berlin via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> Today, the IR requires that if you have multiple edges from A to B >> (typically with a switch) any phi nodes in B must have an equal number of >> entries for A, but that all of them must have the same value. > >> This seems rather annoying.... >> 1) It

> On 25 May 2018, at 01:46, Aaron via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi all, > > LLVM optimization pass gives an error "Terminator found in the middle of a basic block!" since basic block IR may have multiple "ret" instructions. It seems LLVM does not accept multiple return in a basic block by default. > Yes, if you’re inserting

Thank you for the suggestion, Bill. The result is not quite what I would like. Here's sample code for you or anyone else who may be interested: Al1 = c('A','C','C','C') Al2 = c('G','G','G','T') Freq1 = c(0.0078,0.0567,0.9434,0.9908) MAF = c(0.0078,0.0567,0.0566,0.0092) m1 = data.frame(Al1=Al1,

Hi all, LLVM optimization pass gives an error "Terminator found in the middle of a basic block!" since basic block IR may have multiple "ret" instructions. It seems LLVM does not accept multiple return in a basic block by default. Is there a specific optimization or pass that I can enable to remove unreachable codes in basic blocks? Best, Aaron -------------- next part

On Thu, Oct 30, 2014 at 2:33 PM, Robin Morisset <morisset at google.com> wrote: > Hi, > > From my understanding of the LLVM IR, it is impossible to jump to the > middle of a Basic Block, only to its beginning. But there is a > splitBasicBlock function that seems like it might be useful to you, to make > sure a basic block is starting at the exact place you want to jump.

On Thu, Oct 30, 2014 at 4:48 PM, Eric Christopher <echristo at gmail.com> wrote: > > > On Thu Oct 30 2014 at 1:16:38 PM Xiaoguang Wang <xgwang09 at gmail.com> > wrote: > >> On Thu, Oct 30, 2014 at 2:33 PM, Robin Morisset <morisset at google.com> >> wrote: >> >>> Hi, >>> >>> From my understanding of the LLVM IR, it is

On 1/21/11 2:50 PM, Chuck Zhao wrote: > I need to figure out all LLVM Instructions that may write to memory. > > In http://llvm.org/docs/tutorial/OCamlLangImpl7.html, it mentions that > "In LLVM, all memory accesses are explicit with load/store > instructions, and it is carefully designed not to have (or need) an > "address-of" operator." > > I take

On Feb 1, 2011, at 1:34 PM, Andrew Trick wrote: > On Feb 1, 2011, at 1:08 PM, Andrew Clinton wrote: > >> I have a (non-entry) basic block that contains only PHI nodes and an >> unconditional branch (that does not branch to itself). Is it always >> possible to merge this block with it's successor and produce a >> semantically equivalent program? I'm

I'm trying to come up with a simple example of using ICmpInst in a Pass. On each of the branches(true, false) I'd like to call a separate function and then resume(to the code that was already there). In this example i is a inst_iterator to Instruction the Pass is currently on. Now it segfaults opt before I can even get a dump() on it. Does anyone see what I am doing wrong? BasicBlock

Here's what I've got so far - it seems to work, aside from the fact that DeleteDeadPHIs is not removing at least one dead PHI in my test program. --------------------- static bool mergeBlockIntoSuccessor(BasicBlock *pred, BasicBlock *succ) { if (succ == pred) return false; if (pred->getFirstNonPHI() != pred->getTerminator()) return false; //

> 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 figure out all LLVM Instructions that may write to memory. In http://llvm.org/docs/tutorial/OCamlLangImpl7.html, it mentions that "In LLVM, all memory accesses are explicit with load/store instructions, and it is carefully designed not to have (or need) an "address-of" operator." I take this as "StoreInst is the only one that writes to memory". However,

> On 25 May 2018, at 03:53, Aaron <acraft at gmail.com> wrote: > > Hi Dean, > > Thanks for your reply. > > That's exactly what I am doing, but I was looking for a default optimization or pass implementation if there was. > There’s a dead code elimination pass, but it works with a control flow graph (it removes basic blocks that are unreachable after constant