search for: succ_begin

...t; On Tue, Mar 10, 2020 at 8:31 AM Alina Sbirlea <alina.sbirlea at gmail.com> > wrote: > >> Hi Dave, >> >> It may be possible to do this with the current API, but what I was >> looking for is a common API for existing block types. For example there is >> no succ_begin for Machine BasicBlock. >> > >> I'm looking to make the CFGSuccessors and CFGPredecessors classes in >> CFGDiff.h templated, and this needs a common API for all types >> instantiations. >> >> Does this clarify your question or did I misunderstand your sugg...

Hi Dave, It may be possible to do this with the current API, but what I was looking for is a common API for existing block types. For example there is no succ_begin for Machine BasicBlock. I'm looking to make the CFGSuccessors and CFGPredecessors classes in CFGDiff.h templated, and this needs a common API for all types instantiations. Does this clarify your question or did I misunderstand your suggestion? Nicolai, Yes, I considered declaring the "...

...oncrete view of what the changes look like, I uploaded two preliminary patches: (1) part 1: D75881 <https://reviews.llvm.org/D75881>: Introducing class specific iterators (2) D75882 <https://reviews.llvm.org/D75882> (1) part 2: pending: Cleaning up existing usages; example replacement: `succ_begin(BB)` with `BB->succ_begin()`. (1) part3/4: pending: Add class specific iterators to `Instruction` and clean up existing usages just as for `BasicBlock`. I split the above (1) just to clarify what interfaces are added versus the NFC cleanups that follow. But it could be done just as well in a si...

...sformation, which takes 2 & 4 and places them after block 5 is: MachineBasicBlock* newExitPath = findLowestNumSuccBB(root); pHigh->addSuccessor(newExitPath); root->removeSuccessor(newExitPath); root->CorrectExtraCFGEdges(*root->succ_begin(), NULL, false); pHigh->CorrectExtraCFGEdges(*pHigh->succ_begin(), newExitPath, false); newExitPath->moveAfter(pHigh); root->getParent()->RenumberBlocks(); So what am I doing wrong? Thanks, Micah Villmow Systems Engin...

...ze(); i != e; ++i ) { if( seen[i] ) continue; seen[i] = true; MachineBasicBlock * start, *block; start = block = mf.getBlockNumbered(i); std::vector< MachineBasicBlock* > blocks; while( block->succ_size() == 1 && (*block->succ_begin())->pred_size() == 1 ) { block = *block->succ_begin(); seen[block->getNumber()] = true; blocks.push_back( block ); } // TODO: // For each basic block bb in blocks in order of insersion: // 1. Remove basic blocks in the block vec...

...2 & 4 and places them after > block 5 is: > MachineBasicBlock* newExitPath = findLowestNumSuccBB(root); > pHigh->addSuccessor(newExitPath); > root->removeSuccessor(newExitPath); > root->CorrectExtraCFGEdges(*root->succ_begin(), > NULL, false); > pHigh->CorrectExtraCFGEdges(*pHigh->succ_begin(), > newExitPath, false); > newExitPath->moveAfter(pHigh); > root->getParent()->RenumberBlocks(); > > So what am I doing wrong? > > Thank...

Dear LLVM, Is there any simple way to decide whether there is a control path from one Basic Block to another Basic Block? thanks, Jerry

Has anyone written a pass at the MachineFunction level which combines machine basic blocks which is guaranteed to be the single predecessor to another block? Or is there a reason not to combine them? - Thanks Jeff Kunkel

On Oct 6, 2010, at 4:31 PM, Jeff Kunkel wrote: > Has anyone written a pass at the MachineFunction level which combines > machine basic blocks which is guaranteed to be the single predecessor > to another block? Or is there a reason not to combine them? I'm not sure exactly what transformation you're referring to, but BranchFolder::OptimizeBranches does a lot of things like that.

...true; >>>>        MachineBasicBlock * start, *block; >>>>        start = block = mf.getBlockNumbered(i); >>>>        std::vector< MachineBasicBlock* > blocks; >>>>        while( block->succ_size() == 1 && >>>> (*block->succ_begin())->pred_size() == 1 ) { >>>>          block = *block->succ_begin(); >>>>          seen[block->getNumber()] = true; >>>>          blocks.push_back( block ); >>>>        } >>>>        // TODO: >>>>        // For each ba...

...2002, Chris Lattner wrote: > > > Is there any simple way to decide whether there is a control path from one > > Basic Block to another Basic Block? > > No efficient way, but you could do a depth first search... > > If you are looking for a DIRECT connection, try the > succ_begin()/succ_end() iterators (which loop over successors). > > -Chris > > -- > http://llvm.cs.uiuc.edu/ > http://www.nondot.org/~sabre/Projects/ > >

...to build LLVM+Clang from source on MacOSX 10.8+. " /Users/travis/build/vpmedia/crossbridge/llvm-2.9/lib/Transforms/Utils/CodeExtractor.cpp:728:28: [0;1;31m error: no matching constructor for initialization of 'std::vector<BasicBlock *>' std::vector<BasicBlock*> Succs(succ_begin(codeReplacer), " I understand that it is some kind of C++ library issue (stdlibc++ vs. c++v1) but not exactly how to solve it. (Passing -stdlib=libstdc++ as CXX flag does not solve this). You can check out a related github ticket here: https://github.com/Homebrew/homebrew-versions/issues...

...y BasicBlock ends with a terminator instruction, which is one of these: http://llvm.cs.uiuc.edu/docs/LangRef.html#terminators Each terminator has explicit target BasicBlocks (if any), which means you can navigate the CFG directly using the terminators or you can use the API pred_begin/end() and succ_begin/end() found in llvm/include/llvm/Support/CFG.h If you are not sure how to use them, search the code base for one of them to find example usage. > Is there any existing tool that LLVM provides that makes CFG out of > bytecode ? Above I described how to navigate the CFG within your comp...

...exhibit edge-cases of SSA def-use behavior does *not* need to be clever enough to deal with this example, since the verifier rejects this snippet (def of %m does not dominate its use). If all we care about are blocks that have to follow def-dominates-use in the intuitive sense then a super simple succ_begin()/succ_end() based DFS is sufficient. What I don't know is whether such a thing will be fast enough. In any case, I don't have enough experience with LLVM to have a strong / defensible opinion on this, and I'll defer to the decision taken by people who do. -- Sanjoy

...es_end(); A concrete graph needs a constructor that stores a reference to the data that is to look like a graph. e.g. struct BasicBlockGraph { Function& f; BasicBlockGraph(Function& f) : f(f) {} typedef BasicBlock NodeType; ... child_begin(NodeType* node) {return succ_begin(node);} child_begin(NodeType* node) {return succ_end(node);} ... }; An invese graph is just another implementation e.g. struct BasicBlockInverseGraph { ... child_begin(NodeType* node) {return pred_begin(node);} child_begin(NodeType* node) {return pred_end(node);} ... };...

...hineBasicBlock *> 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); } }...

...s.size()) { + // If the block has exactly one successor, that happens to be a + // landingpad, accept it as valid control flow. + if (MBB->succ_size() != 1+LandingPadSuccs.size() && + (MBB->succ_size() != 1 || LandingPadSuccs.size() != 1 || + *MBB->succ_begin() != *LandingPadSuccs.begin())) { report("MBB exits via unconditional branch but doesn't have " "exactly one CFG successor!", MBB); } else if (!MBB->isSuccessor(TBB)) { - Ahmed -------------- next part -------------- A non-text attachment...

...mation, which takes 2 & 4 and places them after block 5 is: MachineBasicBlock* newExitPath = findLowestNumSuccBB(root); pHigh->addSuccessor(newExitPath); root->removeSuccessor(newExitPath); root->CorrectExtraCFGEdges(*root->succ_begin(), NULL, false); pHigh->CorrectExtraCFGEdges(*pHigh->succ_begin(), newExitPath, false); newExitPath->moveAfter(pHigh); root->getParent()->RenumberBlocks(); So what am I doing wrong? Thanks, Micah Villmow Systems Engineer...

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

...is 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-between-external-and-in...