similar to: [LLVMdev] Running specific passes

Displaying 20 results from an estimated 4000 matches similar to: "[LLVMdev] Running specific passes"

2004 Nov 26
0
[LLVMdev] Running specific passes
On Fri, 26 Nov 2004, Vladimir Prus wrote: > in the implementation of some analysis, I need to change the program and then > invoke Mem2Reg pass. That pass, in turn, requires other analysis, so I must Usually you want to do this at a higher level, why not just use 'opt -yourpass -mem2reg'? Alternatively, if you don't want to do that, you can build mem2reg into your pass if it
2004 Nov 29
2
[LLVMdev] Running specific passes
On Friday 26 November 2004 19:56, Chris Lattner wrote: > On Fri, 26 Nov 2004, Vladimir Prus wrote: > > in the implementation of some analysis, I need to change the program and > > then invoke Mem2Reg pass. That pass, in turn, requires other analysis, so > > I must > > Usually you want to do this at a higher level, why not just use 'opt > -yourpass -mem2reg'?
2004 Nov 29
0
[LLVMdev] Running specific passes
On Mon, 29 Nov 2004, Vladimir Prus wrote: > On Friday 26 November 2004 19:56, Chris Lattner wrote: > > On Fri, 26 Nov 2004, Vladimir Prus wrote: > > > in the implementation of some analysis, I need to change the program and > > > then invoke Mem2Reg pass. That pass, in turn, requires other analysis, so > > > I must > > > > Usually you want to do this
2013 Feb 23
2
[LLVMdev] mem2reg for non entry blocks?
Sorry if this has been discussed before, but I would appreciate any pointers. I am trying to understand why mem2reg only looks at allocas in entry blocks, and not for any allocas in a function. One case where allocas could be used to build local data structures like linked list (and so on make it unsafe), and for that the existing conditions in IsAllocaPromotable (i.e. the alloca pointer cannot
2013 Feb 26
0
[LLVMdev] mem2reg for non entry blocks?
Hi Vinod, On 23/02/13 02:20, Vinod Grover wrote: > Sorry if this has been discussed before, but I would appreciate any pointers. > I am trying to understand why mem2reg only looks at allocas in entry blocks, and > not for any allocas in a function. One case where allocas could be used to build > local data structures like linked list (and so on make it unsafe), and for that > the
2011 Nov 08
4
[LLVMdev] loadable passes with dependencies?
Just shows me what I expect void getAnalysisUsage(AnalysisUsage &AU) const { DominatorTree *dt = &getAnalysis<DominatorTree>(); So I'm only using it for DominatorTree(so I can use PromoteMemToReg). Thanks On Tue, Nov 8, 2011 at 2:28 PM, Tobias Grosser <tobias at grosser.es> wrote: > On 11/08/2011 07:33 PM, ret val wrote: >> >> Sorry to keep dragging
2011 Nov 08
2
[LLVMdev] loadable passes with dependencies?
I still have the addRequired: virtual void getAnalysisUsage(AnalysisUsage &AU) const { AU.addRequired<DominatorTree>(); } The other line DominatorTree *dt = &getAnalysis<DominatorTree>(); Is for later use when I try to use PromoteMemToReg On Tue, Nov 8, 2011 at 4:22 PM, Michael Ilseman <michael at lunarg.com> wrote: > Something's
2011 Nov 08
0
[LLVMdev] loadable passes with dependencies?
Something's different here, earlier in the thread you said you had: void getAnalysisUsage(AnalysisUsage &AU) const { AU.addRequired<DominatorTree>(); } Now you have: void getAnalysisUsage(AnalysisUsage &AU) const { DominatorTree *dt = &getAnalysis<DominatorTree>(); I'm sort of confused, why did this change happen? I think the
2011 Nov 08
0
[LLVMdev] loadable passes with dependencies?
On 11/8/11 4:34 PM, ret val wrote: > I still have the addRequired: > virtual void getAnalysisUsage(AnalysisUsage&AU) const { > AU.addRequired<DominatorTree>(); > } > > The other line > DominatorTree *dt =&getAnalysis<DominatorTree>(); > Is for later use when I try to use PromoteMemToReg Isn't DominatorTree a
2011 Nov 09
1
[LLVMdev] loadable passes with dependencies?
Awesome, that let me get far enough to trip: Assertion failed: (ResultPass && "Unable to find requested analysis info"), function getAnalysisID Is there something else I forgot? On Tue, Nov 8, 2011 at 5:47 PM, John Criswell <criswell at illinois.edu> wrote: > On 11/8/11 4:34 PM, ret val wrote: >> >> I still have the addRequired: >>         virtual
2011 Nov 08
0
[LLVMdev] loadable passes with dependencies?
On 11/08/2011 07:33 PM, ret val wrote: > Sorry to keep dragging this out on you. Im now getting: Assertion > failed: (ResultPass&& "getAnalysis*() called on an analysis that was > not " "'required' by pass!"), function getAnalysisID > > But I already have: > void getAnalysisUsage(AnalysisUsage&AU) const { >
2011 Nov 08
2
[LLVMdev] loadable passes with dependencies?
Sorry to keep dragging this out on you. Im now getting: Assertion failed: (ResultPass && "getAnalysis*() called on an analysis that was not " "'required' by pass!"), function getAnalysisID But I already have: void getAnalysisUsage(AnalysisUsage &AU) const { AU.addRequired<DominatorTree>(); } And changed the bottom of my pass too: char Hello::ID =
2013 Feb 26
2
[LLVMdev] mem2reg for non entry blocks?
On Tue, Feb 26, 2013 at 5:42 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Vinod, > > > On 23/02/13 02:20, Vinod Grover wrote: > >> Sorry if this has been discussed before, but I would appreciate any >> pointers. >> I am trying to understand why mem2reg only looks at allocas in entry >> blocks, and >> not for any allocas in a function. One
2013 Mar 03
2
[LLVMdev] Question about method CodeExtractor::severSplitPHINodes
Thanks for reply Chuck. Please excuse me if I'm not supposed to reply to all. Are you saying all PHI nodes are required to include all its predecessor blocks no matter they have input or not? What about successor blocks? Are they optional if they don't provide inputs? BTW, where should I look at to verify this, the mem2reg.cpp & PromoteMemToReg.cpp? Thanks a lot. On Sat, Mar 2, 2013
2013 Feb 26
1
[LLVMdev] mem2reg for non entry blocks?
On 2/26/13 8:06 AM, Duncan Sands wrote: > Hi Justin, > >> an alloca outside of the entry block might be inside a loop, in >> which case the >> semantics are that it would allocate more stack space on every >> loop iteration. >> I think some of the optimizers that run later try to move allocas >> into the entry >> block if possible,
2003 Aug 13
1
[LLVMdev] Running a pass
Hi, I want to run the Mem2Reg pass on a function without using the the LLVM opt utility. I wrote some code, which I am not sure is correct: TS_ASSERT(!verifyFunction(*function)); // find the dominance frontier of the CFG DominanceFrontier DF; DF.runOnFunction(*function); // try to promote stack allocated variables PromoteMemToReg(function->getRegAllocas(), DF, *tgt_data);
2003 Aug 13
1
[LLVMdev] Running a pass
Hi, I assume that since each pass is in its own anonymous namespace, we cannot directly create a new pass object; looking at the code for 'opt' utility, it seems we need a PassInfo object, using which we create a new pass object. I tried the following code (which I wrote after looking at the code for bugpoint), but the list of passes seems to be empty: // Create a list of all the
2010 Jun 07
0
[LLVMdev] Converting into SSA form
E-path PRE requires the program in SSA form like SSAPRE algorithm. Then it finds the eliminatable path (e-path) for an expression and converts partially redundant to fully redundant and removes redundancy Chayan On Mon, Jun 7, 2010 at 1:58 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Sun, Jun 6, 2010 at 8:56 PM, Chayan Sarkar <chayan.ju at gmail.com> wrote: >> Hi
2010 Jun 07
1
[LLVMdev] Converting into SSA form
On Sun, Jun 6, 2010 at 8:56 PM, Chayan Sarkar <chayan.ju at gmail.com> wrote: > Hi Jeffrey, > > Actually I am trying to implement "E-path PRE" which is based on > non-algebric equivallence. So, the  variable names need to be > preserved. Then why do you want to run mem2reg before your optimization in the first place? -Eli
2006 May 03
1
[LLVMdev] Patch for transform dependencies
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