similar to: [LLVMdev] Splitting basic blocks while preserving machine code

On Oct 20, 2010, at 5:16 PM, Trevor Harmon wrote: > I'm writing a pass that does some static analysis on C code. A > critical requirement of the pass is that it must preserve not only the > correctness of the code but also its timing -- It cannot add or remove > even one CPU cycle from the resulting machine code. To put it another > way, the binary executable that is

On Wed, Oct 20, 2010 at 7:19 PM, Jim Grosbach <grosbach at apple.com> wrote: > > On Oct 20, 2010, at 5:16 PM, Trevor Harmon wrote: >> I'm writing a pass that does some static analysis on C code. A >> critical requirement of the pass is that it must preserve not only the >> correctness of the code but also its timing -- It cannot add or remove >> even one CPU

Hi, I'm not sure if this is really a problem or not, but I noticed that if you're working with bitcode that has debug metadata, and you split a BasicBlock using llvm::SplitBlock or BasicBlock::splitBasicBlock, the unconditional branch added to the new block will lack debug metadata. This turned out not to be a problem for me, since my analysis pass needs only one instruction in

On Oct 20, 2010, at 5:26 PM, Kenneth Uildriks wrote: > You could always undo the split right before your pass finishes. How would I undo a split? Perhaps by merging them back using llvm::MergeBlockIntoPredecessor? Trevor

On Oct 27, 2010, at 5:53 PM, Trevor Harmon wrote: > Hi, > > I'm not sure if this is really a problem or not, but I noticed that if > you're working with bitcode that has debug metadata, and you split a > BasicBlock using llvm::SplitBlock or BasicBlock::splitBasicBlock, the > unconditional branch added to the new block will lack debug metadata. > This turned

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

Hello, I would like to see if this issue is a result of a misunderstanding on my part before I file a bug. I am using LLVM 3.4, built from the source tarballs. My system's uname is "Darwin tyler-air 12.5.0 Darwin Kernel Version 12.5.0: Sun Sep 29 13:33:47 PDT 2013; root:xnu-2050.48.12~1/RELEASE_X86_64 x86_64". All I'm trying to do is add a runtime check after all call

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

> 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

On Mar 30, 2010, at 7:51 PM, John Criswell wrote: > I'm too lazy to convert your .dot file into a graph file What format should I have posted? (I'm not sure what you mean by "graph file".) I had thought that .dot was the preferred format here, since that's what LLVM generates (e.g., "opt -dot-cfg ..."). > First, LLVM does not guarantee that a function

Hi, I've written a FunctionPass that happens to be read-only (preserving): It doesn't modify the code in any way; it just does some analysis and dumps out the results for each function by overriding FunctionPass::print. I now need to make some changes to the pass, and these changes will mean that the results cannot be known until all functions have been visited. So there's

On Mar 25, 2010, at 5:23 PM, me22 wrote: > Given that LLVM is already managing the memory and presumably will do > so for the life of your graph processing, could you just use a > boost::directed_graph<llvm::BasicBlock*> instead? Yeah, that was one of the first things I tried: for (Function::iterator i = function.begin(), e = function.end(); i != e; ++i) { BasicBlock

Hi, Yeah I found that it is running LLVM's functions. The functions that are running are: main llvm.dbg.func.start llvm.dbg.stoppoint scanf llvm.dbg.region.end But I dont want all the functions to be called as I am using Dominator Trees and whenever I the statement DominatorTree &DT = getAnalysis<DominatorTree>(F); is encountered by functions other than main, it gives error.

On Wed, Mar 31, 2010 at 2:59 PM, Trevor Harmon <trevor.w.harmon at nasa.gov> wrote: > I'm wondering what would cause a CFG not to have a return block. The > comments in UnifyFunctionExitNodes.cpp say: "If there are no return > stmts in the Function, a null pointer is returned." But this doesn't > make sense; even an empty void function has a return block with a

> 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

Can you please post the code to split a MachineBasicBlock? I am trying to split a MachineBasicBlock at a specific instruction in the MBB, let us say, into MBB1 and MBB2. This instruction should go into MBB2. Also MBB1 should have an unconditional branch to MBB2 as the terminator. (quite similar to splitBasicBlock in BasicBlock.cpp) Meanwhile, I am trying to come up with a variant of

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.

Hi, LLVM provides basic graph traversal for its CFGs, but I need additional operations, such as iterating over the edges. I thought I would solve this problem using the Boost graph library. It should be relatively simple to walk an LLVM CFG and add the BasicBlock objects to a Boost graph declared as: typedef boost::directed_graph<llvm::BasicBlock> Graph; Once constructed, this