search for: unifyfunctionexitnod

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 fine. Domagoj ***************************** PATCH BEGIN ********************************************** Index:...

Hi all, Why are these two passes conflicting: UnifyFunctionExitNodes and LowerSwitch? AU.addRequired(LowerSwitchID) works, so does AU.addRequired<unifyFunctionExitNodes>(), but the two together don't... opt: PassManagerT.h:387: void llvm::PassManagerT<Trait>::markPassUsed(const llvm::PassInfo*, llvm::Pass*) [with Trait = llvm::MTraits]: Asserti...

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 predecessors recursively. — Gordon -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-d...

...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>(); AU.addRequired<LoopInfo>(); AU.addPreserved<LoopInfo>(); } bool MyPass::runOnFunction(Function &function) { LoopInfo &loopInfo = getAnalysis<LoopInfo>(); ... } I don't know how to convert the above code into its equivalent form for a Mo...

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

...to have only 1 return instruction. That sounds like a good approach, except that this pass does not appear to produce a CFG with exactly one return block, but rather one or zero return blocks. The distinction is important because if the pass's getReturnBlock function returns null (see UnifyFunctionExitNodes.h), I'm back to square one of not having a single exit block. 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...

...unctions 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 isn't currently designed to schedule prerequisite *transform* passes (like UnifyFunctionExitNodes). If your pass requires that another transform pass be executed first, then the PassManager must be explicitly told (via the PassManager.add() method) to run that pass first. If you're running your pass via the opt tool, then it means that the user must manually specify the prerequisite...

...ant. >>> >> >> I had considered that, but my FunctionPass depends on other passes >> processing the functions first: >> > > Two things to consider: > > 1) The PassManager isn't currently designed to schedule prerequisite > *transform* passes (like UnifyFunctionExitNodes). If your pass requires > that another transform pass be executed first, then the PassManager must > be explicitly told (via the PassManager.add() method) to run that pass > first. If you're running your pass via the opt tool, then it means that > the user must manually specify...

I have a ModulePass, which we'll call MP, that generates a dependency graph for an entire program. I want MP to require the UnifyFunctionExitNodes pass, which is a FunctionPass. Since its not possible to make a ModulePass depend on a FunctionPass, is my only choice to make MP a FunctionPass in which the runOnFunction() routine does nothing, and the doFinalization routine does all the work that the runOnModule() pass did when MP was a M...

...t;must be available throughout the lifetime of the pass". For example, if a pass is "available" when my pass runs, then I should be able to use it when my pass is running, correct? For instance: void MyPass::getAnalysisUsage(AnalysisUsage &AU) const { AU.addRequired<UnifyFunctionExitNodes>(); } bool MyPass::runOnFunction(Function &function) { UnifyFunctionExitNodes &pass = getAnalysis<UnifyFunctionExitNodes>(); // ... use the pass ... } But if the above is okay, then why would addRequiredTransitive be necessary? I suspect that the REQUIRES definitio...

...er "ID" as the passes in the "Transforms/Utils" directory. All the passes in the "IPO" directory only have a "run()" function that inherits from the "llvm/IR/PassManager.h". I am not quite sure how to invoke these passes in my own pass. I used "UnifyFunctionExitNodes" in my pass and this one worked fine. It will be a great help if anyone can point out how to call the "CalledValuePropagationPass" in my own pass. Thanks, Zi -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-...

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 ret > instruction inside it. Is there some other kind of source code pattern > that would cause an...

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

...uch conflicting passes within a single pass that requires them both b) Sequencing and "property preservation" still look like optimization to me (a very useful, but also limiting one). If runOnFunction() calls are assumed to be independent, for each function, the PassManager could call: UnifyFunctionExitNodes which destroys all properties, and LowerSwitchID, which should be able to rebuild what it needs. The order might be implementation-dependent, and that's the only problem I see. However, in this case those two passes do orthogonal transforms, and it doesn't really matter which runs first...

...; /dev/null" to the opt command, but that suppresses the entire error stream, which isn't good. I also tried converting my FunctionPass into a ModulePass, and iterating over the functions manually, but I ran into problems because I can't seem to require a function pass, such as UnifyFunctionExitNodes, to run on a function if I'm within a ModulePass. Any other suggestions? Thanks, Trevor

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

...time/../.. > And then i can't do gmake install :) > > Ok > I will rebuld llvm and check build logs for crtend.a creating and > installing > Current CVS LLVM build without problems but gmake install failed with message: /home/wanderer/pkg/llvm/include/./llvm/Transforms/Utils/UnifyFunctionExitNodes.h /home/wanderer/pkg/llvm/include/./llvm/IntrinsicInst.h gmake[1]: Entering directory `/usr/home/wanderer/pkg/build/llvm/obj/lib/System' llvm[1]: Compiling MappedFile.cpp for Debug build /home/wanderer/pkg/build/llvm/src/llvm/lib/System/MappedFile.cpp:27:35: platform/MappedFile.cpp: No such...

>> All SingleSource and MultiSource tests failed in last run of FreeBSD >> nighttester (and in previous). >> Mostly with error: > > This looks like your crtend.a file did not get built correctly. Try doing > make clean/make install in llvm/runtime/ again. > gmake clean in llvm/runtime/ remove all build tree of nighttest starting with llvm/runtime/../.. And then i

Hi, I'm confused about the entry and exit blocks of an LLVM CFG. I understand that every CFG has one and only one entry block, and this is confirmed by the existence of the getEntryBlock function in the Function class. But what about exit (a.k.a. return) blocks? At first I assumed that LLVM CFGs have one and only one exit block, too, but the following code is a counter-example: