search for: unifyexitnod

...>> 1. It seems that there is ONLY ONE ReturnInst(and NO InvokeInst) for such >> llvm IR; is it legal to add other *ReturnInst*s when transforming? >> > > An LLVM function can have multiple ReturnInsts as long as each one > terminates a basic block. There is a transform (UnifyExitNodes, IIRC) that > will take a function with multiple ReturnInsts and create one with a single > ReturnInst. Having a single ReturnInst (exit node) simplifies other > analyses. > > Thanks so much, John; especially for pointing out 'UnifyExitNodes' pass! > > >> 2. I...

...source code into llvm IR: > > 1. It seems that there is ONLY ONE ReturnInst(and NO InvokeInst) for such > llvm IR; is it legal to add other *ReturnInst*s when transforming? An LLVM function can have multiple ReturnInsts as long as each one terminates a basic block. There is a transform (UnifyExitNodes, IIRC) that will take a function with multiple ReturnInsts and create one with a single ReturnInst. Having a single ReturnInst (exit node) simplifies other analyses. > > 2. Is it possible for a frontend to generate a function whose CFG is > something like: > > bb0...

...y > > block, which blocks are exit blocks? Is there any efficient way to > > dicectly get that information? > > Given a function you can always use Function::getEntryBlock() to get the > entry block. You need to scan the function to get the returning nodes. You could also use UnifyExitNode (a pass in analysis) to unify the exits, and then use getExit() to get the exit node. -anand

Hi, this question might be a bit silly: apart from the language reference(http://llvm.org/docs/LangRef.html#switch-instruction) page, are there additional rules for a regular llvm frontend to generate llvm IRs? There are a few cases that I got from clang/llvm-gcc/dragonegg when compiling *C* source code into llvm IR: 1. It seems that there is ONLY ONE ReturnInst(and NO InvokeInst) for such llvm

Wenbin Zhang wrote: > I'll try the trunk, as well as check my code again. If indeed it's not > fixed, I'll try to post a triggering case here. > Thanks for the advice~ > Did you run the -mergereturn pass (it might also be called UnifyExitNodes in the source code)? This is the pass that ensures that each function has exactly one basic block that returns control to the caller. It's possible that PostDominator doesn't handle functions with multiple exits (if someone knows whether it does or not, please let me know). -- John T....

On 08/05/2010 06:46 AM, Wenbin Zhang wrote: > Hi all, > I'm using postDominatorTree to do some program analysis. My code works > well for small tests, but when I run it on real applications, the > following error occurs: > /Inorder PostDominator Tree: DFSNumbers invalid: 0 slow queries. > [1] <<exit node>> {0,21} > [2] %bb1 {1,2} > [2] %bb {3,4} > [2]

...;() to require each FunctionPass, but I think the PassManager will run the passes automatically as needed. > > Note that you cannot use the PassManager to ensure that certain optimization passes are run before your pass is run. If you need to run an optimization pass before your pass (e.g., UnifyExitNodes), then you need to tell the PassManager to run it before your pass explicitly. > > Regards, > > John Criswell > >> >> Félix >> >>> Le 2015-05-19 à 10:12:32, John Criswell <jtcriswel at gmail.com <mailto:jtcriswel at gmail.com>> a écrit :...

Thanks John. Does this solve the problem of analysis availability though? If I still have to run the function analyses manually, I might as well keep rolling with the CallGraphSCCPass. (I probably should have mentioned that this is what I’m using right now.) Félix > Le 2015-05-19 à 10:12:32, John Criswell <jtcriswel at gmail.com> a écrit : > > On 5/18/15 10:45 PM, Félix Cloutier

...ll wrote: > Wenbin Zhang wrote: >> I'll try the trunk, as well as check my code again. If indeed it's not >> fixed, I'll try to post a triggering case here. >> Thanks for the advice~ >> > > Did you run the -mergereturn pass (it might also be called > UnifyExitNodes in the source code)? This is the pass that ensures that > each function has exactly one basic block that returns control to the > caller. > > It's possible that PostDominator doesn't handle functions with multiple > exits (if someone knows whether it does or not, please le...

Dear LLVM, I want to know, given a function, How do I know which block is entry block, which blocks are exit blocks? Is there any efficient way to dicectly get that information?

I'll try the trunk, as well as check my code again. If indeed it's not fixed, I'll try to post a triggering case here. Thanks for the advice~ Best, --Wenbin ----- Original Message ----- From: "Tobias Grosser" <grosser at fim.uni-passau.de> To: "Wenbin Zhang" <zhangwen at cse.ohio-state.edu> Cc: <llvmdev at cs.uiuc.edu> Sent: Thursday, August

On Wed, Mar 1, 2017 at 12:53 PM, John Criswell via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 3/1/17 2:54 PM, Peizhao Ou via llvm-dev wrote: > > Hi everyone, > > I am currently testing out a combination of IR->IR passes with opt to > benchmark how they affect performance. The source code works fine if simply > use the clang (-O0/-O3) to directly compile to

On 6/19/16 4:28 AM, Mehdi Amini via llvm-dev wrote: > >> On Jun 18, 2016, at 10:44 PM, Yuxi Chen via llvm-dev >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Hi All, >> >> When I use llvm, I encounter a problem like "unable to schedule pass >> A required by C" >> I investigated deeper.