similar to: [LLVMdev] PassManager

Chris and Devang, Before you implement the LoopPassManager class, I'd like to discuss this a little bit. I have a suggestion and a question; we can discuss this now or later, as you wish: 1. The LoopPassManager might become much simpler if the more complex loop passes are given control over how they iterate over the loops, rather always rely on the manager to enumerate the loops in

Hi Vikram, On Nov 7, 2006, at 10:19 AM, Vikram Adve wrote: > Chris and Devang, > > Before you implement the LoopPassManager class, I'd like to discuss > this a little bit. I have a suggestion and a question; we can > discuss this now or later, as you wish: > > 1. The LoopPassManager might become much simpler if the more complex > loop passes are given control over

Devang, I read Chris's notes so I got all this information there already. My comments were in response to that. --Vikram http://www.cs.uiuc.edu/~vadve http://llvm.cs.uiuc.edu/ On Nov 7, 2006, at 12:34 PM, Devang Patel wrote: > Hi Vikram, > > On Nov 7, 2006, at 10:19 AM, Vikram Adve wrote: > >> Chris and Devang, >> >> Before you implement the

On Tue, 7 Nov 2006, Vikram Adve wrote: > 1. The LoopPassManager might become much simpler if the more complex > loop passes are given control over how they iterate over the loops, > rather always rely on the manager to enumerate the loops in some > fixed order. Then the pass could be responsible for making sure that > it handles issues like loops that are deleted during the pass.

On Nov 7, 2006, at 2:02 PM, Chris Lattner wrote: > On Tue, 7 Nov 2006, Vikram Adve wrote: >> 1. The LoopPassManager might become much simpler if the more complex >> loop passes are given control over how they iterate over the loops, >> rather always rely on the manager to enumerate the loops in some >> fixed order. Then the pass could be responsible for making sure

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

Is there a transformation in LLVM that will perform loop fusion? http://en.wikipedia.org/wiki/Loop_fusion I have the following program, in which I would like the 2 loops (iterating the same number of times) to be merged into 1, after which other nice optimizations such as mem2reg will apply: ; ModuleID = 'test' define void @vector([16 x float]* nocapture %arg, [16 x float]* nocapture

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

I did find this note from 2004 that references a LoopFusion pass, but I can't find it in the source code: http://nondot.org/sabre/LLVMNotes/LoopOptimizerNotes.txt A little background - I'm working on a SIMD runtime, where I have a scalar program but need to execute it on multiple independent data elements. One approach is to generate a loop for each operation, then rely on the

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

Hello, (fairly new around here, apologies if the question has an obvious answer) I've been studying the structure of the new PassManager in the hopes of using it soon. After watching a couple of talks (Chandler / Sergeev), I decided to start with the Concept/Model classes in PassManagerInternal.h While I could make sense of almost everything there, two details caught my attention: 1- The

Hello Matthijs, On May 9, 2008, at 3:47 AM, Matthijs Kooijman wrote: > 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

On Tue, 7 Nov 2006, Vikram Adve wrote: >> I think I see the issue here. The point of the pass manager (in >> general) >> is for passes to *give up control* over iteration order in order for >> obtain something else. > > > Right, I understand that. I think that works fine in most cases. > For loop passes, though, this approach is causing some of the >

On Wed, 8 Nov 2006, Vikram Adve wrote: > ... you would relax that policy for cases where the pass wants > control over its order of visitation. In fact , some passes (e.g., > loop tiling) may want to do two or more transforms on a set of loops > at a time. E.g., loop tiling needs to do strip-mining on a loop, > then interchange one of the resulting loops with *some* outer loop

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

hi all, I want access to all basic blocks of function in a loop, so I used the following code: *bool parallel::runOnLoop(Loop *L, LPPassManager &LPM) { for (Function::iterator bi= func->begin(); bi != func->end(); bi++){ // } }* First loop run without problem, but for second loop I get the following error: *0 libLLVM-2.9.so 0x0137d530 1 libLLVM-2.9.so 0x0137fa6c 2

On Nov 7, 2006, at 6:32 PM, Chris Lattner wrote: > On Tue, 7 Nov 2006, Vikram Adve wrote: >>> I think I see the issue here. The point of the pass manager (in >>> general) >>> is for passes to *give up control* over iteration order in order for >>> obtain something else. >> >> >> Right, I understand that. I think that works fine in most

Hi Michael, +CC llvm-dev My guess is that it would be rather error prone to pinpoint exact places where we start populating new LPPassManager since it’s created lazily via LoopPass::assignPassManager. So we are risking to miss adding verifiers in some of the LPPassManager’s. One similar idea is to introduce LCSSAVerifier function pass and make LCSSA pass to be dependant on it. That will allow

Hi, I am begineer to llvm, implementing a main.cpp from https://github.com/davidar/lljvm/blob/master/backend/main.cpp A) : When I am declaring a command: * PassManager PM* * PM.add(new DataLayout td)* It shows error: > *error: missing template arguments before ‘PM’* * PassManager PM;* ^ >*main_test.cpp:48:2: error: ‘PM’ was not declared in this scope* *