search for: succ_iterator

Hi, As part of an ongoing work to extend the GraphDiff (this models a CFG view), I came across the need to have a common interface for accessing successors/predecessors in various IR units, such that a type such as `typename NodeT::succ_iterator` could be used in templated code. In particular, the need arose for BasicBlocks, MachineBasicBlocks, VPBlockBase and clang::CFGBlock. The least invasive change seemed to be to use the interface already being used in MachineBasicBlock and clang::CFGBlock, and: (1) update BasicBlock to use this inst...

...; wrote: > >> Hi, >> >> As part of an ongoing work to extend the GraphDiff (this models a CFG >> view), I came across the need to have a common interface for accessing >> successors/predecessors in various IR units, such that a type such as >> `typename NodeT::succ_iterator` could be used in templated code. >> > > I /think/ this can be achieved with the existing API by using > "decltype(succ_begin(std::declval<NodeT>()))" instead of the typename > you've got as an example (it looks like succ_begin is the extension point - > but...

Hello, I try to make a big CFG (control flow graph) by combining all the CFG-s from all the functions of a module. I still have one problem : I want to get the links between functions. For CFG-s, I used CallGraphNode->second->getFunction, then Function_iterators and succ_iterators, so I have all the links between BBs. Now, the questions is how do I link BBs from different functions? I can do it in a way not so elegant. Take the last BB of every function, then getTerminator and see that function it is called and then link to (instruction-2-instruction). There must be there...

...aph) by combining all the CFG-s >> from all >> the functions of a module. I still have one problem : I want to get the >> links >> between functions. >> >> For CFG-s, I used CallGraphNode->second->**getFunction, then >> Function_iterators >> and succ_iterators, so I have all the links between BBs. Now, the >> questions is >> how do I link BBs from different functions? >> >> I can do it in a way not so elegant. Take the last BB of every function, >> then >> getTerminator and see that function it is called and then link...

Hi, this is a bit of a newbie question: I am trying to discover, given a block with a conditional and its successors, which condition (T/F) each successor applies to. There's almost identical code in CFGPrinter.cpp, but where it gets called in GraphWriter.h, the child_iterator type is a pretty hairy thing, so I still don't quite understand how to get one from a BasicBlock in my own

...gt; > I try to make a big CFG (control flow graph) by combining all the CFG-s from all > the functions of a module. I still have one problem : I want to get the links > between functions. > > For CFG-s, I used CallGraphNode->second->getFunction, then Function_iterators > and succ_iterators, so I have all the links between BBs. Now, the questions is > how do I link BBs from different functions? > > I can do it in a way not so elegant. Take the last BB of every function, then > getTerminator and see that function it is called and then link to > (instruction-2-instructio...

...gt; >>>> As part of an ongoing work to extend the GraphDiff (this models a CFG >>>> view), I came across the need to have a common interface for accessing >>>> successors/predecessors in various IR units, such that a type such as >>>> `typename NodeT::succ_iterator` could be used in templated code. >>>> >>> >>> I /think/ this can be achieved with the existing API by using >>> "decltype(succ_begin(std::declval<NodeT>()))" instead of the typename >>> you've got as an example (it looks like succ...

...e CFG-s > from all > the functions of a module. I still have one problem : I want to get the > links > between functions. > > For CFG-s, I used CallGraphNode->second->__getFunction, then > Function_iterators > and succ_iterators, so I have all the links between BBs. Now, the > questions is > how do I link BBs from different functions? > > I can do it in a way not so elegant. Take the last BB of every function, > then > getTerminator and see that function it is call...

...ions use the dominance tree to decide where it's safe to insert new instructions and it always assumes that if A dom B then an instruction in A is always accessible in B. Here's the new plan. Please poke holes in it. A. redefine the CFG a bit. i. pred_iterator stays the same. ii. succ_iterator only iterates over successors iii. outedge_iterator iterates over successors and the unwind dest There's still some code which refers to outedges by TerminatorInst + unsigned. I can't think of any reason not to replace all of them with outedge_iterator. B. redefine the dominator tree...

...h I am not sure whether this is actually right or whether I exclude to many calls this way). But there appear to be CALL32r instructions that also call locations outside the program. Is there any way to determine the location of the call target more precisely? I tried for (MachineBasicBlock::succ_iterator SI = BB->succ_begin(), SE = BB->succ_end(); SI != SE; ++SI) { MachineBasicBlock *SBB = *SI; if (SBB->getParent()->getFunction()->isDeclaration()) skip = true; } but it seems not to do what I intended. -- View this message in context: http://www.nabble.com/How-to-differentiate-...

Hello, I would like to extract Control Flow Graph and Data Flow Graph from a sample program written in C++, Can anybody please direct me to some examples? Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20101012/fc071e63/attachment.html>

Sorry -- Small change. Nick Lewycky wrote: > A. redefine the CFG a bit. > i. pred_iterator stays the same. pred_iterator becomes an inverse of outedge_iterator. That is, edges that lead to the execution of this block, regardless of whether it's an unwind-edge or not. Nick

...t the end of every basic block even if that should simply > be a branch to the start of the next block. Is this indeed the case? Yup, every basic block must end with a terminator. The terminators are what build the implicit CFG in LLVM (ie, the presence of terminators makes pred_iterator & succ_iterator work on basic blocks). > If it is, it would be "user friendly" to simply supply the branch > instruction. That is, provide a method on Function that appends a > BasicBlock to the end of the block list. If the existing final basic > block doesn't have a terminating instru...

...SumForBlock in lib/CodeGen/MachineBranchProbability.cpp used getEdgeWeight(MBB*, MBB*), which always return the weight of the first edge to the default block, i.e., it calculated the sum of the weights as 24+16+24+16+16 = 96. In LLVM 3.2 getSumForBlock was changed to use getEdgeWeight(MBB*, MBB::succ_iterator), causing it to calculate the sum of weights now correctly as 24+16+16+16+16 = 88. However, in include/llvm/Analysis/BlockFrequencyImpl.h:202 doBlock() uses getEdgeProbability(MBB*, MBB*) when iterating over the ingoing edges of the default block, which only returns the probability for the fir...

> 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

...mf) { std::vector<MachineBasicBlock *> src_blocks; std::vector<MachineBasicBlock *> dst_blocks; // first, only find the critical edges: for(unsigned u = 0; u < mf.size(); u++) { MachineBasicBlock * mbb = mf.getBlockNumbered(u); for(MachineBasicBlock::succ_iterator succ = mbb->succ_begin(); succ != mbb->succ_end(); succ++) { MachineBasicBlock * mbb_succ = *succ; if(is_critical_edge(*mbb, *mbb_succ)) { src_blocks.push_back(mbb); dst_blocks.push_back(mbb_succ);...

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 Tue, 4 Jul 2006, Fernando Magno Quintao Pereira wrote: > However, it does not remove all the critical edges. I am getting a very > weird dataflow graph (even without the Break Critical edges pass). The > dataflow generated by MachineFunction::dump() for the program below is > given here: > http://compilers.cs.ucla.edu/fernando/projects/soc/images/loop_no_crit2.pdf ... > The

Newbie Question .. (sorry if its redundant/silly) .. As I've started to develop Stacker, I had assumed that simply adding BasicBlocks to a function in sequence would imply that there is an implicit unconditional branch from the end of one basic block to the start of the next block. Based on the assertion checks that I get when I tried this, I assume that it is required to place a terminating

...of the successors of the New block (which // _were_ the successors of the 'this' block), and update any PHI nodes in // successors. If there were PHI nodes in the successors, then they need to // know that incoming branches will be from New, not from Old. // for (llvm::succ_iterator I = llvm::succ_begin(newBlock), E = llvm::succ_end(newBlock); I != E; ++I) { // Loop over any phi nodes in the basic block, updating the BB field of // incoming values... llvm::BasicBlock *Successor = *I; for (auto &PN : Successor->phis()) {...