search for: runinliner

...m would produce a seg-fault in LLVM (haven't checked further, though), but I know that is one of: PM.add(createGlobalOptimizerPass()); PM.add(createConstantMergePass()); PM.add(createDeadArgEliminationPass()); PM.add(createInstructionCombiningPass()); // Inline small functions if (RunInliner) PM.add(createFunctionInliningPass()); PM.add(createPruneEHPass()); // Remove dead EH info. if (RunInliner) PM.add(createGlobalOptimizerPass()); PM.add(createGlobalDCEPass()); // Remove dead functions. Then I looped over all LTO passes in the populateLTOPassManager() but adding th...

...ManagerBuilder.h (working copy) @@ -132,8 +132,14 @@ /// populateModulePassManager - This sets up the primary pass manager. void populateModulePassManager(PassManagerBase &MPM); - void populateLTOPassManager(PassManagerBase &PM, bool Internalize, - bool RunInliner, bool DisableGVNLoadPRE = false); + + /// setup passes for Pre-IPO phase + void populatePreIPOPassMgr(PassManagerBase &MPM); + + void populateIPOPassManager(PassManagerBase &PM, bool Internalize, + bool RunInliner); + + void populatePostIPOPM(PassManagerBase...

Andy and I briefly discussed this the other day, we have not yet got chance to list a detailed pass order for the pre- and post- IPO scalar optimizations. This is wish-list in our mind: pre-IPO: based on the ordering he propose, get rid of the inlining (or just inline tiny func), get rid of all loop xforms... post-IPO: get rid of inlining, or maybe we still need it, only

Hi Renato, On 08/01/13 17:16, Renato Golin wrote: > After looking at the Livermore for a while, we found the issue that was causing > LTO to produce a different result. > > Consider the code below [1]. setup() doesn't touch bar/baz, main() doesn't > reference foo. LTO finds, correctly, I don't think this is correct. At the LLVM IR level it is valid to write into bar

After looking at the Livermore for a while, we found the issue that was causing LTO to produce a different result. Consider the code below [1]. setup() doesn't touch bar/baz, main() doesn't reference foo. LTO finds, correctly, that it can remove the setup(), but the result is different. The code is clearly wrong, but the compiler has no right to fix user's stupidity, even at that