similar to: [LLVMdev] PassManager vs. FunctionPassManager

On Fri, Jun 4, 2010 at 7:49 AM, David Greene <dag at cray.com> wrote: > What's the point of having two pass managers here?  Why not just use > "Passes" for everything? This is done to replicate what llvm-gcc does. First pass manager to optimizer each function individually at the end of the function. Second pass manager to optimize entire module. Add

Thanks. The reason I ask is because I'm looking at some code that does just that. A single FunctionPassManager is constructed with a dummy Module and createStandardFunctionPasses is called on it. The FunctionPassManager cached and run on Functions in other Modules. So far I haven't noticed any problems but I guess that is because the passes added by createStandardFunctionPasses don't

Right now, addPassesToEmitFile requires a FunctionPassManager. If I'm working with code that uses a plain PassManager and want it to generate code, are there any options better than doing this: /** * Wrapper class to run a FunctionPassManager as a ModulePass so that it * can be added to a plain PassManager. */ class FunctionPassManagerModulePass : public ModulePass { FunctionPassManager

On Jun 21, 2007, at 4:13 PM, Dan Gohman wrote: > Right now, addPassesToEmitFile requires a FunctionPassManager. If I'm > working with code that uses a plain PassManager and want it to > generate > code, are there any options better than doing this: That's what FPPassManager does (include/llvm/PassManagers.h) . Function pass manager itself is a module level pass.

On Thu, Jun 21, 2007 at 04:37:14PM -0700, Devang Patel wrote: > > On Jun 21, 2007, at 4:13 PM, Dan Gohman wrote: > > > Right now, addPassesToEmitFile requires a FunctionPassManager. If I'm > > working with code that uses a plain PassManager and want it to > > generate > > code, are there any options better than doing this: > > That's what

On Tue, Mar 22, 2011 at 11:51 AM, Peter Zion <peter.zion at fabric-engine.com> wrote: > Hello, > > I am trying to modify my LLVM-based compiler to perform an initial, no-optimization compilation synchronously on startup and then perform an asynchronous, optimized recompilation in the background, and I am getting in one of the optimization passes. > > - I am using the official

On Fri, Mar 5, 2010 at 5:53 AM, George Giorgidze <giorgidze at gmail.com> wrote: > > Hi Erick, > > Can you make the following functions available in llvm-c. > > createStandardFunctionPasses > createStandardModulePasses > createStandardLTOPasses > > Thanks in advance, George This is a little tricky, so I need some advice from the community. First off, I'm

Hello, I am trying to modify my LLVM-based compiler to perform an initial, no-optimization compilation synchronously on startup and then perform an asynchronous, optimized recompilation in the background, and I am getting in one of the optimization passes. - I am using the official release of LLVM 2.8 - I have compiled LLVM with threading enabled; I am running llvm::llvm_start_multithreaded() on

On 1/10/06, Chris Lattner <sabre at nondot.org> wrote: > Interesting approach. :) Thanks. > Comments below, with ***'s before the notes: > +class LoopPass : public Pass {}; // Temporary. > > *** I wouldn't worry about loop passes yet. Sure. > +class PassUnit { > + Pass *pass; > + > + enum Traversal { > + LINEAR, // Standard top down

Erick Tryzelaar <erick.tryzelaar <at> gmail.com> writes: > > I've pretty much finished exposing all I wanted to llvm-c and the > ocaml bindings for the soon to be released 2.7. Does anyone need any > other functions exposed before the code freeze on the 7th? > Hi Erick, Can you make the following functions available in llvm-c. createStandardFunctionPasses

On 09/23/2011 11:28 AM, Redmond, Paul wrote: > Hi, > > Is it generally safe to cache a FunctionPassManager and reuse it on > modules other than the one it was constructed with (assuming they have > the same target triple)? No. FunctionPass has a pair of methods, doInitialization and doFinalization, which take Module& and are allowed to read or modify it outside runOnFunction.

> Date: Wed, 26 Oct 2011 11:52:50 -0700 > From: Tanya Lattner <lattner at apple.com> > Subject: [LLVMdev] Release Notes: Volunteers needed > We need some volunteers to help with the 3.0 release notes. Traditionally, Chris has been the one to go > through all the commits (6 months worth!) and come up with a concrete list of things that have changed in 3.0. > Ideally,

Hi, Is it generally safe to cache a FunctionPassManager and reuse it on modules other than the one it was constructed with (assuming they have the same target triple)? paul -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110923/cd845b59/attachment.html>

On Mon, 9 Jan 2006, Saem Ghani wrote: > The patch below basically hammers out some ideas as to where I'd like > to take the passmanager in LLVM. I've tried thinking things through, > but I'm still a n00b, so some criticism would be more than welcome. =) > > Starting from line 191 down. If you're wondering why I created a > patch, well that's because I found

The loop rotation pass does modify the function, which I'm guessing means that a FunctionPassManager can be used to run LoopPasses (this is not obvious to me after looking through the FunctionPassManager code). Unfortunately none of the other passes I'm using (ScalarEvolution, LCSSA, IndVarSimplify, and LoopUnroll) appear to have an effect. I verified that the function can be loop

On Wed, Oct 17, 2012 at 12:58 PM, Chris Lattner <clattner at apple.com> wrote: > > On Oct 17, 2012, at 7:34 AM, Kostya Serebryany <kcc at google.com> wrote: > > Hello, > > I've recently changed AddressSanitizer (asan) compiler pass from > ModulePass to FunctionPass and it could a bit of mayhem. > > The problem is that asan FunctionPass instruments a

Hello, > On Apr 26, 2018, at 6:44 AM, Son Tuan VU <sontuan.vu119 at gmail.com> wrote: > > Hi Vedant, > > I have tried to implement the fix you proposed, but it didn't work as expected. I created a new Module Pass Manager (not Function Pass Manager) and override the add() method like this: > > class DebugifyEachPassManager : public legacy::PassManager { >

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 Vedant, I have tried to implement the fix you proposed, but it didn't work as expected. I created a new *Module* Pass Manager (not Function Pass Manager) and override the *add()* method like this: class DebugifyEachPassManager : public legacy::PassManager { public: void add(Pass *P) override { PassManager::add(createDebugifyPass()); PassManager::add(P);