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

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.

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

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

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

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

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 function foo, then foo gets inlined into bar, then bar gets instrumented > and thus the code of foo

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 function foo, then foo gets inlined into bar, then bar gets instrumented and thus the code of foo gets instrumented twice (which causes run-time crash). This happens only at -O0; at -O1 we get the correct order of

"Daniel Stewart" <stewartd at codeaurora.org> writes: > I'm no expert on the PassManager, but I happen to be going through it > fairly carefully right now. You didn't state which passes were Module > Passes and which were Function Passes (or other types). Sorry, I did mean to include that. They are all FunctionPasses. > One thing I have noticed is that