similar to: [LLVMdev] CFG entry and exit blocks

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

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

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 Jul 22, 2010, at 2:05 PM, John Criswell wrote: > If you write your pass as a ModulePass, then you can iterate over the > functions in any order that you want. I had considered that, but my FunctionPass depends on other passes processing the functions first: void MyPass::getAnalysisUsage(AnalysisUsage &AU) const { AU.addRequired<UnifyFunctionExitNodes>();

John Criswell wrote: > Trevor Harmon wrote: >> On Jul 22, 2010, at 2:05 PM, John Criswell wrote: >> >> >>> If you write your pass as a ModulePass, then you can iterate over the >>> functions in any order that you want. >>> >> >> I had considered that, but my FunctionPass depends on other passes >> processing the functions first:

Hi, I need to do an inverse-depth-first iteration over the basic blocks in a machine function (i.e. starting from the last block and following predecessor edges) for a liveness analysis I'm writing. idf_iterator seems like it's almost the class I need, but it starts at the first block in the function at present, rather than the last one (because of the specialisiation of GraphTraits for

Trevor Harmon wrote: > On Jul 22, 2010, at 2:05 PM, John Criswell wrote: > > >> If you write your pass as a ModulePass, then you can iterate over the >> functions in any order that you want. >> > > I had considered that, but my FunctionPass depends on other passes > processing the functions first: > Two things to consider: 1) The PassManager

On 2007-03-18, at 03:22, Lang Hames wrote: > Is there a recommended way to find the final block (the one with > successors={}) in a machine function? This isn't a property of the CFG in the general case. However, the UnifyFunctionExitNodes transformation/analysis provides it. From getAnalysis<UnifyFunctionExitNodes>().getReturnBlock(), you can visit the basic block

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

Hi, I would like my FunctionPasses to be invoked in reverse call graph order (callees before callers). However, "Writing an LLVM Pass" notes that "FunctionPass's do not require that they are executed in a particular order." Is there any way at all to specify an ordering? If this is not possible, I'm thinking of a workaround in which my runOnFunction method

Trevor Harmon wrote: > Hi, > > I would like my FunctionPasses to be invoked in reverse call graph > order (callees before callers). However, "Writing an LLVM Pass" notes > that "FunctionPass's do not require that they are executed in a > particular order." Is there any way at all to specify an ordering? > > If this is not possible, I'm

Is there a facility with which we may automagically create a "fake" exit node, one that is the target of all BasicBlocks ending in return. This would be very helpful to IP dataflow analysis... Dave

Hi, I'm trying to solve a problem from StructurizeCFG not actually handling regions with multiple exits. Sample IR attached. StructurizeCFG doesn't touch this function, exiting early on the isTopLevelRegion check. SIAnnotateControlFlow then gets confused and ends up inserting an if into one of the blocks, and the matching end.cf into one of the return/unreachable blocks. The input to

Would it make sense to have a similar pass that operates on llvm main IR? On Sat, May 8, 2010 at 5:15 PM, Dale Johannesen <dalej at apple.com> wrote: > The branch folding pass does this, but it operates later, on the > target-dependent form in llc. > > On May 8, 2010, at 8:48 AM, Heinz Riener wrote: > >> Dear all, >> >> after optimizing a small LLVM example

Eugene Toder wrote: > Would it make sense to have a similar pass that operates on llvm main IR? > The unify exit return node (-mergereturn?) pass should take care of the first example. The -simplifycfg option might take care of the second example. Both work on LLVM IR. -- John T. > On Sat, May 8, 2010 at 5:15 PM, Dale Johannesen <dalej at apple.com> wrote: > >>

Hi Henrique, I have tried using -mergereturn and inserting a free into the predecessors of dominance frontier of malloc block and it caused double free. It is possible for multiple free's to be inserted on the path from malloc to an exit. For example, in the following CFG: BB10 (malloc) / \ BB11 BB12 ... / \ / \

Hi, A number of transforms are actually independent, so here's a partial fix. I updated the dependencies in a cluster of transforms: LowerSwitch, Mem2Reg, LowerSelect, LowerAllocations, UnifyFunctionExitNodes. The patch has been tested, but not extensively. PassManager doesn't complain, and the result of a test pass that requires all these (except for LowerAllocations) together works

Hello,  I wish to reduce a function CFG to its entry block. I wrote the following code using lib/IR/Function.cpp/Function::dropAllReferences() (from llvm-3.6) as reference:  Function *F; // Suitably initialized. BasicBlock *FEntryBlock = &F->getEntryBlock(); FEntryBlock->getTerminator()->eraseFromParent(); FEntryBlock->removeFromParent(); for (Function::iterator I = F->begin(),

On Fri, 29 Nov 2002, Anand Shukla wrote: > There is a pass "UnifyFunctionExitNodes()" (you can add it to AnalysisUsage > of your pass) that does the trick. Yup, just like Anand says, this pass will make it so that there is at most one exit node from the function, which you can use for your analysis (it will even tell you which BB that is too). Note that a function may _not_ have

Jakub Staszak wrote: > Hi, > > It looks like PDT.getRootNode() returns NULL for: > > define fastcc void @c974001__lengthy_calculation. > 1736(%struct.FRAME.c974001* nocapture %CHAIN.185) noreturn { > entry: > br label %bb > > bb: > br label %bb > } > > > Isn't it a bug in PostDominatorTree? > > Please note that this crashes: >