search for: ep_loopoptimizerend

Hi Tobias, I am trying to move Polly later. LLVM provides some predefined ExtensionPointTy: EP_EarlyAsPossible, EP_ModuleOptimizerEarly, EP_LoopOptimizerEnd, EP_ScalarOptimizerLate, ... Currently Polly uses "EP_EarlyAsPossible" to run as early as possible. As what you suggested: >Instead of removing canonicalization passes, I believe we may want to >move Polly to a later place in the pass manager. Possibly at the >beginn...

On 09/19/2013 04:46 PM, Star Tan wrote: > Hi Tobias, > > > I am trying to move Polly later. > > > LLVM provides some predefined ExtensionPointTy: > EP_EarlyAsPossible, > EP_ModuleOptimizerEarly, > EP_LoopOptimizerEnd, > EP_ScalarOptimizerLate, > ... > > > Currently Polly uses "EP_EarlyAsPossible" to run as early as possible. As what you suggested: >> Instead of removing canonicalization passes, I believe we may want to >> move Polly to a later place in the pass ma...

...tionPass()); // Delete dead loops if (EnableLoopInterchange) { MPM.add(createLoopInterchangePass()); // Interchange loops MPM.add(createCFGSimplificationPass()); } if (!DisableUnrollLoops) MPM.add(createSimpleLoopUnrollPass()); // Unroll small loops addExtensionsToPM(EP_LoopOptimizerEnd, MPM); // <GVN is now immediately after loop optimizatons if (OptLevel > 1) { MPM.add(createMergedLoadStoreMotionPass()); // Merge ld/st in diamonds MPM.add(NewGVN ? createNewGVNPass() : createGVNPass(DisableGVNLoadPRE)); // Remove redundancies } This cause...

On 09/17/2013 04:12 AM, Star Tan wrote: > Now, we come to more evaluations on http://188.40.87.11:8000/db_default/v4/nts/recent_activity Hi Star Tan, thanks for this very extensive analysis. The results look very interesting. As you found out, just removing some canonicalization passes will reduce compile time, but this reduction may in large part being due to Polly not being able to

...s> wrote: >On 09/19/2013 04:46 PM, Star Tan wrote: >> Hi Tobias, >> >> >> I am trying to move Polly later. >> >> >> LLVM provides some predefined ExtensionPointTy: >> EP_EarlyAsPossible, >> EP_ModuleOptimizerEarly, >> EP_LoopOptimizerEnd, >> EP_ScalarOptimizerLate, >> ... >> >> >> Currently Polly uses "EP_EarlyAsPossible" to run as early as possible. As what you suggested: >>> Instead of removing canonicalization passes, I believe we may want to >>> move Polly to...

....es> wrote:>On 09/19/2013 04:46 PM, Star Tan wrote: >> Hi Tobias, >> >> >> I am trying to move Polly later. >> >> >> LLVM provides some predefined ExtensionPointTy: >>      EP_EarlyAsPossible, >>      EP_ModuleOptimizerEarly, >>      EP_LoopOptimizerEnd, >>      EP_ScalarOptimizerLate, >>      ... >> >> >> Currently Polly uses "EP_EarlyAsPossible" to run as early as possible.  As what you suggested: >>> Instead of removing canonicalization passes, I believe we may want to >>> move Polly to...

Now, we come to more evaluations on http://188.40.87.11:8000/db_default/v4/nts/recent_activity I mainly care about the compile-time and execution time impact for the following cases: pBasic (run 45): clang -O3 -load LLVMPolly.so pNoGenSCEV (run 44): clang -O3 -load LLVMPolly.so -polly-codegen-scev -polly -polly-optimizer=none -polly-code-generator=none pNoGenSCEV_nocan (run 47): same option

...s()); // Delete dead loops + + if (/*LoopVectorize &&*/ OptLevel > 1 && SizeLevel < 2) + PM.add(createLoopVectorizePass()); + + if (!DisableUnrollLoops) + PM.add(createLoopUnrollPass()); // Unroll small loops + + addExtensionsToPM(EP_LoopOptimizerEnd, PM); + + if (OptLevel > 1) + PM.add(createGVNPass()); // Remove redundancies + + PM.add(createInstructionCombiningPass()); + PM.add(createDeadStoreEliminationPass()); // Delete dead stores + PM.add(createAggressiveDCEPass()); // Delete dead in...

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