similar to: [LLVMdev] Why is BasicBlock's copy constructor private?

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

On 25 March 2010 20:04, Trevor Harmon <trevor.w.harmon at nasa.gov> wrote: > > So why exactly is BasicBlock's copy constructor private? The ominous > "Do not implement" warning leads me to think there is some sort of > design issue that is preventing a copy constructor here. Is there any > possibility of working around it? > I think the problem is that LLVM

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

On Mon, May 10, 2010 at 8:05 PM, Trevor Harmon <Trevor.W.Harmon at nasa.gov> wrote: > On May 10, 2010, at 8:43 AM, Xinfinity wrote: > >> Is it possible to get the list of BasicBlocks building the condition >> of a loop and the list of BasicBlocks that form the body? > > Based on my (limited) experience with Loop and LoopInfo, this isn't > possible. (But

Edwin, thank you for your effort, but I'm not sure I understand. Are you describing a graph traversal problem? Is the data model stored in a predecessor/successor fashion, which requires you to 'walk' the graph in order to visit all nodes? (and what happens when you have disjointed DFGs?). inline comments follow... Török Edwin wrote: > On 2009-09-06 17:30, Ioannis Nousias

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

Wenbin Zhang wrote: > ----- Original Message ----- > From: "John Criswell" <criswell at illinois.edu> > To: "Wenbin Zhang" <zhangwen at cse.ohio-state.edu> > Cc: <llvmdev at cs.uiuc.edu> > Sent: Friday, August 27, 2010 5:09 PM > Subject: Re: [LLVMdev] how to check whether from basicblock A we can go to > basicblock B within the same

Edwin, thanks, it starts making sense inline comments... Török Edwin wrote: > On 2009-09-06 19:57, Ioannis Nousias wrote: > >> Edwin, >> >> thank you for your effort, but I'm not sure I understand. >> Are you describing a graph traversal problem? Is the data model stored >> in a predecessor/successor fashion, which requires you to 'walk' the

On 2009-09-06 19:57, Ioannis Nousias wrote: > Edwin, > > thank you for your effort, but I'm not sure I understand. > Are you describing a graph traversal problem? Is the data model stored > in a predecessor/successor fashion, which requires you to 'walk' the > graph in order to visit all nodes? (and what happens when you have > disjointed DFGs?). Sorry for the

On 5/3/11 4:14 PM, tarun agrawal wrote: > Hi > > I have clone a basic block using CloneBasicBlock function but it does > not clone the predecessor with it. I am not able to figure out, how to > set the predecessor of the cloned basic block. LLVM's CFG is explicitly maintained by the terminator instructions within each basic block. In order to change the CFG, you have to

On Jun 1, 2011, at 5:03 PM, Jakub Staszak wrote: > I just found a small bug. Fixed version attached. > > <kuba_bp3.patch> Committed as r132613 (and r132616). Thanks Jakub! To help reviewers understand the patch and where we're headed with it, I've prepared the following design documentation. For now I'm sending it to llvm-dev until we have an official design doc for

On May 10, 2010, at 11:05 AM, Trevor Harmon wrote: >>> To me it looks like any basic block from the loop body with a >>> successor not in the loop body is a BB "building the condition" (an >>> "exit" block). >> >> I assume you mean "any basic block from the loop header". > > No really, loop body. In that case, what does

Dear Trevor, I'm too lazy to convert your .dot file into a graph file, but I'll make some comments anyway. :) First, LLVM does not guarantee that a function has a single exit block. Multiple basic blocks can have a return instruction as their terminator instruction. There is a pass (Unify Function Exit nodes i.e., -mergereturn <http://llvm.org/docs/Passes.html#mergereturn>)

Hi, I got a problem when I am trying to add a dummy basic block. Let say there are two blocks, A and B. A----->B I am trying to generate new BB called C which is located between A and B, but not break the edge of AB. The graph is like the following A---->B \ / \ / C There is new BB 'C' with edges AC and CB. It is kind of like what breakcriticaledge pass does.

On Mon, May 10, 2010 at 12:32:06PM -0700, Trevor Harmon wrote: > On May 10, 2010, at 11:35 AM, Benoit Boissinot wrote: > > >To me it looks like any basic block from the loop body with a > >successor not in the loop body is a BB "building the condition" (an > >"exit" block). > > I assume you mean "any basic block from the loop header".

Yes, that would be better. -----Original Message----- From: Guoliang Jin <jingl1345 at gmail.com> Sent: Friday, August 27, 2010 5:05 PM To: llvmdev at cs.uiuc.edu <llvmdev at cs.uiuc.edu> Subject: Re: [LLVMdev] how to check whether from basicblock A we can go to basicblock B within the same function? > Every basic block ends with a terminator instruction that indicates >

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

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

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