similar to: [LLVMdev] Patch for transform dependencies

Displaying 20 results from an estimated 600 matches similar to: "[LLVMdev] Patch for transform dependencies"

2006 Jul 25
1
[LLVMdev] Dubious Library Dependencies
Now that we have a "-why" option to the GenLibDeps.pl utility (which is used by llvm-config to deduce library dependencies), a review of the output has led to a few dubious library dependencies. Here they are: All of the following dependencies are singletons (the dependent library depends on only a single symbol from the dependency library): libLLVMCodeGen.a:
2006 May 03
2
[LLVMdev] Conflicting passes?
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]: Assertion `getAnalysisOrNullUp(P)
2006 May 03
1
[LLVMdev] Conflicting passes?
Hi, > On Wed, 3 May 2006, Domagoj D wrote: > > I thought so. However, it's not clear to me why "preservation" is > > required at all? > > That's just an optimization. The PassManager should be able to > > run passes with > > interdependencies by serializing them (for example in the order as they were > > added to the queue). > >
2012 Apr 12
0
[LLVMdev] Function Pass Manager
Hi again, I come back to this issue with an example. It's a pass which does nothing but throw the 'Unable to schedule' error. namespace { struct MyPass : public FunctionPass { static char ID; // Pass identification, replacement for typeid MyPass() : FunctionPass(ID) { initializeMyPassPass(*PassRegistry::getPassRegistry()); } virtual void
2012 Mar 23
3
[LLVMdev] Function Pass Manager
Hi, I'm writing a function pass which is dynamically loaded by opt and I need some analysis and passes to be run before my pass: virtual void getAnalysisUsage(AnalysisUsage &AU) const { AU.addRequired<LoopInfo>(); AU.addPreserved<LoopInfo>(); AU.addRequiredID(LoopSimplifyID); AU.addPreservedID(LoopSimplifyID);
2012 Aug 06
3
[LLVMdev] How to call some transformation passes (LoopRotate and LoopUnroll) from my own pass
Hello, I wrote my own pass which needs to do some loop unrolling. I can perform loop unrolling via opt: opt -mem2reg -loops -loop-simplify -loop-rotate -lcssa -loop-unroll -unroll-count=50 mytest.bc -o mytest.bc This command works perfectly. However, what I really want is to produce the **same behavior** but from my own pass (i.e., I don't want to use opt). I wrote a Module pass which
2013 Apr 03
1
[LLVMdev] YSU_Student
Hello, I wrote my own pass which needs to do some loop unrolling. I can perform loop unrolling via opt: opt -mem2reg -loops -loop-simplify -loop-rotate -lcssa -loop-unroll -unroll-count=50 mytest.bc -o mytest.bc This command works perfectly. However, what I really want is to produce the **same behavior** but from my own pass (i.e., I don't want to use opt). I wrote a Module pass which
2007 Mar 18
0
[LLVMdev] idf_iterator and MachineFunctions
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
2010 Mar 31
2
[LLVMdev] CFG entry and exit blocks
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
2012 Aug 06
0
[LLVMdev] How to call some transformation passes (LoopRotate and LoopUnroll) from my own pass
On Aug 6, 2012, at 6:04 AM, Jorge Navas <navas at comp.nus.edu.sg> wrote: > > Hello, > > I wrote my own pass which needs to do some loop unrolling. > > I can perform loop unrolling via opt: > > opt -mem2reg -loops -loop-simplify -loop-rotate -lcssa -loop-unroll > -unroll-count=50 mytest.bc -o mytest.bc > > This command works perfectly. > >
2010 Jul 23
0
[LLVMdev] Controlling the order of a FunctionPass
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
2010 Jul 24
2
[LLVMdev] Controlling the order of a FunctionPass
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:
2010 Jul 22
3
[LLVMdev] Controlling the order of a FunctionPass
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>();
2014 Sep 29
2
[LLVMdev] questions about getAnalysisUsage
Hi, I notice that there are several different methods called inside getAnalysisUsage(). The parameters of addRequiredID and addPreservedID are passID. What is the difference between Required and Preserved? There are also function named addRequired<PassName>() called. What is the difference between addRequired<PassName>() and addRequiredID(PassID)? Thanks a lot! Best,
2006 Oct 08
1
[LLVMdev] modulepass requiring a functionpass
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
2009 Feb 19
2
[LLVMdev] -fPIC warning on every compile on Cygwin
On Thu, Feb 19, 2009 at 6:55 PM, Nick Lewycky <nicholas at mxc.ca> wrote: > Aaron Gray wrote: > > On Thu, Feb 19, 2009 at 5:52 PM, Nick Lewycky <nicholas at mxc.ca > > <mailto:nicholas at mxc.ca>> wrote: > > > > Aaron Gray wrote: > > > Hi, > > > > > > I partly built LLVM on Cygwin yesterday and it was fine
2011 May 16
2
[LLVMdev] InstructionCombining.cpp inconsistency in whether it modifies the CFG?
InstCombine says in its getAnalysisUsage that it preserves the CFG, but for the 4th argument in its INITIALIZE_PASS call, it says false, which I believe corresponds to whether it preserves the CFG. Is this a mistake, or is there deeper meaning here? InstructionCombining.cpp:73-82 char InstCombiner::ID = 0; INITIALIZE_PASS(InstCombiner, "instcombine", "Combine
2012 Jun 05
2
[LLVMdev] Function Pass Manager
On 4/12/12 3:32 AM, Ivan Llopard wrote: > Hi again, > > I come back to this issue with an example. It's a pass which does > nothing but throw the 'Unable to schedule' error. > > namespace { > struct MyPass : public FunctionPass { > static char ID; // Pass identification, replacement for typeid > MyPass() : FunctionPass(ID) { >
2009 Feb 25
3
[LLVMdev] -fPIC warning on every compile on Cygwin
On Sat, Feb 21, 2009 at 7:14 PM, Nick Lewycky <nicholas at mxc.ca> wrote: > Aaron Gray wrote: > > On Thu, Feb 19, 2009 at 6:55 PM, Nick Lewycky <nicholas at mxc.ca > > <mailto:nicholas at mxc.ca>> wrote: > > > > Aaron Gray wrote: > > > On Thu, Feb 19, 2009 at 5:52 PM, Nick Lewycky <nicholas at mxc.ca > >
2009 Feb 21
0
[LLVMdev] -fPIC warning on every compile on Cygwin
Aaron Gray wrote: > On Thu, Feb 19, 2009 at 6:55 PM, Nick Lewycky <nicholas at mxc.ca > <mailto:nicholas at mxc.ca>> wrote: > > Aaron Gray wrote: > > On Thu, Feb 19, 2009 at 5:52 PM, Nick Lewycky <nicholas at mxc.ca > <mailto:nicholas at mxc.ca> > > <mailto:nicholas at mxc.ca <mailto:nicholas at mxc.ca>>> wrote: