search for: createloopsimplifypass

...he PassManagerBuilder.cpp to run some canonicalization routines and redo unrolling again. I have set partial unrolling on + have a huge threshold + allows expensive loop trip counts. Still it didn't unroll by 2. MPM.add(createLoopUnrollPass()); MPM.add(createCFGSimplificationPass()); MPM.add(createLoopSimplifyPass()); MPM.add(createLoopRotatePass(SizeLevel == 2 ? 0 : -1)); MPM.add(createLCSSAPass()); MPM.add(createIndVarSimplifyPass()); // Canonicalize indvars MPM.add(createLoopUnrollPass()); Digging deeper I found, that it fails in UnrollRuntimeLoopRemainder function, where it is unable to calc...

...I am doing: MyPass : ModulePass { bool runOnModule(mod) { for some Functions f in mod { (do some stuff) ExistingModuleProvider mp(mod); FunctionPassManager* fpm = new FunctionPassManager(&mp); fpm->add(createLowerSwitchesPass()); fpm->add(createBreakCriticalEdgesPass()); fpm->add(createLoopSimplifyPass()); fpm2->run(*f); mp.releaseModule(); (do more stuff) } } } Now what I want to have is some runtime-output of the pass manager that tells me what passes were run in what order, give me timing information if possible etc. I hope my explanation is better this time :). Cheers, Ralf

...ing pass (llvm::createFunctionInliningPass), then these passes: - own FunctionPass - llvm::createPromoteMemoryToRegisterPass - llvm::createInstructionCombiningPass - llvm::createDeadInstEliminationPass - llvm::createDeadStoreEliminationPass - new llvm::DominatorTree() - new llvm::LoopInfo() - llvm::createLoopSimplifyPass() - own FunctionPass The problem is that the last function pass (and maybe the others too) gets called with functions that the inlining pass is supposed to delete. this behavior I only saw on windows and macos in 64 bit release mode. In debug mode it works and I think at least on windows it wor...

...canonicalization routines and redo unrolling again. I have set > partial unrolling on + have a huge threshold + allows expensive loop trip > counts. Still it didn't unroll by 2. > > MPM.add(createLoopUnrollPass()); > > MPM.add(createCFGSimplificationPass()); > > MPM.add(createLoopSimplifyPass()); > > MPM.add(createLoopRotatePass(SizeLevel == 2 ? 0 : -1)); > > MPM.add(createLCSSAPass()); > > MPM.add(createIndVarSimplifyPass()); // Canonicalize indvars > > MPM.add(createLoopUnrollPass()); > > > Digging deeper I found, that it fails in UnrollRuntimeL...

...>>> partial unrolling on + have a huge threshold + allows expensive loop trip >>> counts. Still it didn't unroll by 2. >>> >>> MPM.add(createLoopUnrollPass()); >>> >>> MPM.add(createCFGSimplificationPass()); >>> >>> MPM.add(createLoopSimplifyPass()); >>> >>> MPM.add(createLoopRotatePass(SizeLevel == 2 ? 0 : -1)); >>> >>> MPM.add(createLCSSAPass()); >>> >>> MPM.add(createIndVarSimplifyPass()); // Canonicalize indvars >>> >>> MPM.add(createLoopUnrollPass()); >&g...

On Sun, Jul 26, 2009 at 1:48 PM, Ralf Karrenberg<Chareos at gmx.de> wrote: > Hey Daniel, > > thanks for the response. > >> I believe all you need to do is call llvm::llvm_shutdown(). >> > I am not sure that this is what I need. When and how should I call > llvm_shutdown()? At the end of the program, this just arranges for LLVM's "managed statics"

...eProvider mp(mod); > FunctionPassManager* fpm = > new FunctionPassManager(&mp); I think creating a new Function Pass Manager inside a module pass is not ideal, however... > > fpm->add(createLowerSwitchesPass()); > fpm->add(createBreakCriticalEdgesPass()); > fpm->add(createLoopSimplifyPass()); > > fpm2->run(*f); > > mp.releaseModule(); > > (do more stuff) > } > > } > > } > > > Now what I want to have is some runtime-output of the pass manager that > tells me what passes were run in what order, give me timing information > if possible...

Hey Daniel, thanks for the response. > I believe all you need to do is call llvm::llvm_shutdown(). > I am not sure that this is what I need. When and how should I call llvm_shutdown()? After the FunctionPassManager is done, the calling ModulePass still performs quite a few actions on the transformed code and also calls the FunctionPassManager on different functions. However, I need

...ss), then these passes: > - own FunctionPass > - llvm::createPromoteMemoryToRegisterPass > - llvm::createInstructionCombiningPass > - llvm::createDeadInstEliminationPass > - llvm::createDeadStoreEliminationPass > - new llvm::DominatorTree() > - new llvm::LoopInfo() > - llvm::createLoopSimplifyPass() > - own FunctionPass > > The problem is that the last function pass (and maybe the others too) > gets called > with functions that the inlining pass is supposed to delete. I think this is a normal consequence of how the pass manager schedules passes. Suppose you have the followin...

.../scratch/tpondich/ParallelAssert/llvm-objects/tools/opt/Debug+Asserts/opt.o llvm::IntervalPartition::ID /n/fs/scratch/tpondich/ParallelAssert/llvm-objects/tools/opt/Debug+Asserts/opt.o llvm::EnableDebugBuffering /n/fs/scratch/tpondich/ParallelAssert/llvm-objects/tools/opt/Debug+Asserts/opt.o llvm::createLoopSimplifyPass() /n/fs/scratch/tpondich/ParallelAssert/llvm-objects/tools/opt/Debug+Asserts/opt.o llvm::Pass::~Pass() /n/fs/scratch/tpondich/ParallelAssert/llvm-objects/tools/opt/Debug+Asserts/GraphPrinters.o llvm::createScalarReplAggregatesPass(int, bool)/n/fs/scratch/tpondich/ParallelAssert/llvm-objects/tools/...