similar to: [LLVMdev] deleting passes/cloning pass manager

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.

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 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 May 26, 2009, at 3:15 PM, Jeffrey Yasskin wrote: > In Unladen Swallow we (intend to) compile each function as we > determine it's hot. To "compile" a function means to translate it from > CPython bytecode to LLVM IR, optimize the IR using a > FunctionPassManager, and JIT the IR to machine code. We'd like to > include inlining among our optimizations. Currently

Hello, I am working on an LLVM-based JIT for a dynamically typed language (freemat.sf.net), and would like to commend the LLVM team on an awesome piece of work. One issue I ran into that I was hoping for some clarification. Nominally, I had started out by performing code generation from the AST into a function that was added to the current module. I then ran a PassManager on that module to

Hello, @Anastasis: what do you think about this? Do you mind if I implement the debugify-each mode and refactor the code to have DebugifyFunctionPass and DebugifyLoopPass? I am sorry if it bothers you, I should have done this earlier, so you could focus on fixing the optimization passes. FYI, my debugify-each is quite ready, I am having Debugify and CheckDebugify before and after each ModulePass,

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

Hello We are migrating from 2.9 to 3.2 Here is some code that does not compile any more llvm::PassManager *pm; llvm::FunctionPassManager *fpm; module = llvm::ParseBitcodeFile(mb,context,&err_str); if (!module) { error() <<"Failed to load module from bitcode file: " <<err_str <<endl; exit(1); } pm = new PassManager();

In Unladen Swallow we (intend to) compile each function as we determine it's hot. To "compile" a function means to translate it from CPython bytecode to LLVM IR, optimize the IR using a FunctionPassManager, and JIT the IR to machine code. We'd like to include inlining among our optimizations. Currently the Inliner is a CallGraphSCCPass, which can only be run by the

Hello All, I have two questions, one more of an implementation question, the other more a design question. First: I noticed that if one moves the FPPassManager::doInitialization(Module) call from FPPassManager::runOnModule to MPPassManager::runOnModule (which is the new location I am aiming for to avoid the need for a doInitialization/doFinalization outside of the run methods, as preferred by

Hello All, I have two questions, one more of an implementation question, the other more a design question. First: I noticed that if one moves the FPPassManager::doInitialization(Module) call from FPPassManager::runOnModule to MPPassManager::runOnModule (which is the new location I am aiming for to avoid the need for a doInitialization/doFinalization outside of the run methods, as preferred by

I added your suggestion and am using this now llvm::legacy::FunctionPassManager *functionPassManager = new llvm::legacy::FunctionPassManager(Mod); llvm::PassRegistry &registry = *llvm::PassRegistry::getPassRegistry(); initializeScalarOpts(registry); functionPassManager->add( new llvm::TargetLibraryInfoWrapperPass(llvm::TargetLibraryInfoImpl(targetMachine->getTargetTriple())) );

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 08/27/2010 11:05, Dale Johannesen wrote: >>>> Function only has on BB. Is this wrong that it has both >>>> TCRETURNri64 and RET in one BB? >>> >>> Yes, that is wrong. The reason emitEpilogue isn't lowering the >>> TCRETURN is that it doesn't see it, it only sees the RET. The real >>> problem will be where that RET is

On Sun, 21 Jan 2007, Marcel Weiher wrote: > just installed the new llvm 1.9 build and noticed that my code no > longer worked. It seems something has changed with > addPassesToEmitFile(). First, the arguments to that method changed so > that it no longer takes a PassManager, but only a > FunctionPassManager. Instead there is a addPassesToEmitWholeFile() > method, but that is

Hi folks, just installed the new llvm 1.9 build and noticed that my code no longer worked. It seems something has changed with addPassesToEmitFile(). First, the arguments to that method changed so that it no longer takes a PassManager, but only a FunctionPassManager. Instead there is a addPassesToEmitWholeFile() method, but that is marked as optional, and when I change my code to

Daniel Dunbar wrote: > Ah, in this case llvm_shutdown isn't what you are looking for. I've > never looked at the Statistic implementation so I can't be any help > here, but if you poke around starting with "llvm/ADT/Statistic.h" you > may find a way to do what you want. I looked into that already, but Statistic.h only gives me the possibility to implement tracking

Larry, On Wed, Aug 11, 2010 at 4:55 PM, Larry Gritz <lg at larrygritz.com> wrote: > I have a whole slew of questions about optimization passes. Answers to any > or all would be extremely helpful: > > How important are doInitialization/doFinalization? Most of the passes do not use them. > I can't detect any difference if I use them or not. Say, if you are writing

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

Hello, in the implementation of some analysis, I need to change the program and then invoke Mem2Reg pass. That pass, in turn, requires other analysis, so I must use PassManager. Here's the code I ended up with: bool runOnFunction(llvm::Function& m) { visit(m); ExistingModuleProvider mp(m.getParent());