similar to: [LLVMdev] Why should we have the LoopPass and LoopPassManager? Can we get rid of this complexity?

On Wed, Jan 22, 2014 at 12:33 AM, Andrew Trick <atrick at apple.com> wrote: > > There appear to be two chunks of "functionality" provided by loop passes: > > > > 1) A worklist of loops to process. This is very rarely used: > > 1.1) LoopSimplify and LoopUnswitch add loops to the queue. > > I’m making this up without much thought, but we may benefit

On Wed, Jan 22, 2014 at 1:01 AM, Andrew Trick <atrick at apple.com> wrote: > On Jan 22, 2014, at 12:44 AM, Chandler Carruth <chandlerc at gmail.com> > wrote: > > > On Wed, Jan 22, 2014 at 12:33 AM, Andrew Trick <atrick at apple.com> wrote: > >> > There appear to be two chunks of "functionality" provided by loop >> passes: >> >

Hi Tim, > From: Tim Creech <tcreech at umd.edu> > Subject: [LLVMdev] IVUsers (LoopPass) analysis in a ModulePass? > Date: September 1, 2011 11:46:28 AM PDT > To: llvmdev at cs.uiuc.edu > > Hi all, > I have a loadable ModulePass which does transformations, and I would like to > use IVUsers analysis within it. I noticed when I try to do this (via > the usual

Hi, I would like to give a quick update on what my current design and implementation go like. Basically, the `FunctionToLoopPassAdaptor` is now modified to a generic version `FunctionToLoopUnitPassAdaptor`, which allows re-using the existing codes to implement `FunctionToLoopNestPassAdaptor`, with the help of additional metadata associated with `Loop` and `LoopNest`. Both

Are LoopPasses allowed to maintain state between runOnLoop invocations? The documentation is not clear on this point. -Dave

Hi, Thanks for your help! I've checked the sources that you mentioned. Currently, I think that I would need to implement a FunctionToLoopNestPassAdaptor which is essentially the same as the FunctionToLoopPassAdaptor but operates only on LI.getTopLevelLoops(). We might also need a LNPMUpdater (LoopNestPassManagerUpdater) which disallows adding inner-loops back into the pipeline, and

On Aug 19, 2008, at 12:32 PM, David Greene wrote: > Are LoopPasses allowed to maintain state between runOnLoop > invocations? What kind of information are you looking to maintain between runOnLoop invocations ? > > The documentation is not clear on this point. doInitialization() and doFinalization() will be run for each pass before and after runOnLoop(). For each pass

Hi, I'm a college student who is quite new to the community and is interested in contributing to the LLVM project. Although I haven't applied to GSoC, I notice that the project "Create LoopNestPass" seems to be unassigned. So I'm curious whether anyone is currently working on it, and if not, is it possible for me to work on it as a side-project? I've been programming in

Hi all, I have a loadable ModulePass which does transformations, and I would like to use IVUsers analysis within it. I noticed when I try to do this (via the usual addRequired<IVUsers>() and getAnalysis<IVUsers>(*F)), opt fails an assert: opt: /home/tcreech/build/llvm-2.9/include/llvm/PassAnalysisSupport.h:239: AnalysisType& llvm::Pass::getAnalysisID(const void*,

Hi All, the attached patch performs the splitting in the proposed manner. before applying the patch, please execute svn cp lib/Transforms/Scalar/LoopUnroll.cpp lib/Transforms/Utils/UnrollLoop.cpp to make the patch apply and preserve proper history. Transforms/Utils/UnrollLoop.cpp contains the unrollLoop function, which is now used by the LoopUnroll pass. I've also moved the

So, there are two primary ideas behind SSA form management in the loop optimizers of LLVM: - Require LCSSA form input, leverage its (very powerful) guarantees to simplify maintaining SSA form, and also maintain LCSSA form. - Don't bother with LCSSA form input, assume the worst, and use powerful incremental SSA formation utilities built on SSAUpdater to form SSA on demand when needed. (Note,

This probably just works around a layering violation. Can you provide the cmake line that produces a broken build? Cheers, Rafael On Jun 18, 2016 7:34 AM, "Nicolai Hähnle" <llvm-dev at lists.llvm.org> wrote: Hi, since recently I'm getting linker failures in debug builds. The root cause is that -fvisibility-inlines-hidden causes inline functions in explicit template

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

Hello Matthijs, Separating mechanism from policy is a good thing for the LoopUnroll pass. Instead of moving the policy to a subclass though, I think it'd be better to move the mechanism, the unrollLoop function, out to be a standalone utility function, with the LoopInfo object passed in explicitly. FoldBlockIntoPredecessor would also be good to make into a standalone utility function, since

Just to add a few notes... On Tue, Jan 21, 2014 at 1:31 PM, Andrew Trick <atrick at apple.com> wrote: > Chandler suggested a way around the problem. I'll work on that first. > > > It is very difficult to deal with the LoopPassManager. The concept doesn’t > fit with typical loop passes, which may need to rerun function level > analyses, and can affect code outside the

Hi, I have a general question on LoopUnswtich pass. Consider the following IR snippet: define i32 @test(i1 %cond) { br label %loop_begin loop_begin: br i1 %cond, label %loop_body, label %loop_exit loop_body: br label %do_something do_something: call void @some_func() noreturn nounwind br label %loop_begin loop_exit: ret i32 0 } declare void @some_func() noreturn After running

I am trying to add an analysis pass as a FunctionPass, and let LICM (LoopPass) depends upon it. So in LICM.cpp, I have the following: virtual void getAnalysisUsage(AnalysisUsage &AU) const { AU.setPreservesCFG(); AU.addRequired<DominatorTree>(); AU.addRequired<LoopInfo>(); AU.addRequiredID(LoopSimplifyID); AU.addRequired<AliasAnalysis>();

Hello, We currently generate suboptimal code for this loop: for (int i = 1; i < LEN; i++) { a[i] = a[0] + b[i]; } The largest problem is that we won't vectorize the loop because the loop vectorizer does not grok the independence of a[i] and a[0] (note that i starts at 1 in this loop). While we can probably fix the vectorizer to handle this, I don't think that is the right place for

On Tuesday 19 August 2008 15:15, Devang Patel wrote: > On Aug 19, 2008, at 12:32 PM, David Greene wrote: > > Are LoopPasses allowed to maintain state between runOnLoop > > invocations? > > What kind of information are you looking to maintain between runOnLoop > invocations ? Cached analysis answers. > > The documentation is not clear on this point. > >

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