search for: ep_scalaroptimizerl

...-------------Index: include/llvm/Transforms/IPO/PassManagerBuilder.h===================================================================--- include/llvm/Transforms/IPO/PassManagerBuilder.h    (revision 144800)+++ include/llvm/Transforms/IPO/PassManagerBuilder.h (working copy)@@ -67,7 +67,12 @@   /// EP_ScalarOptimizerLate - This extension point allows addingoptimization   /// passes after most of the main optimizations, but before the last   /// cleanup-ish optimizations.-    EP_ScalarOptimizerLate+ EP_ScalarOptimizerLate,++    /// EP_EnabledOnOptLevel0 - This extension point allows adding passes that+    /// sho...

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 >beginning of the loop optimizer...

...at needs to get executed after the coroutine is resumed or destroyed. We also create a struct that will keep the objects that need to persist across suspend points. This transformation is done by CoroSplit CGSCC pass run as a part of the IPO optimizations pipeline. CoroElide Pass: (Function Pass @ EP_ScalarOptimizerLate extension point) --------------- The coroutine resumption intrinsics get replaced with direct calls to those outlined functions where possible. Then inliner can inline much leaner and nicer coroutine or any of the outlined parts as desired. If we discover that the lifetime of a coroutine is ful...

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 manager. Possibly at the >>...

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

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

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

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

...ld keep it like this. I don't have a better solution, but wanted to write down my thoughts. > } > > PassManagerBuilder::~PassManagerBuilder() { > @@ -170,6 +176,14 @@ void PassManagerBuilder::populateModulePassManager(PassManagerBase&MPM) { > > addExtensionsToPM(EP_ScalarOptimizerLate, MPM); > > + if (Vectorize) { > + MPM.add(createBBVectorizePass()); > + if (OptLevel> 1) { > + MPM.add(createInstructionCombiningPass()); > + MPM.add(createGVNPass()); // Remove redundancies > + } > + } > + What is the reason y...

...er solution, but > wanted to write down my thoughts. > > > > } > > > > PassManagerBuilder::~PassManagerBuilder() { > > @@ -170,6 +176,14 @@ void PassManagerBuilder::populateModulePassManager(PassManagerBase&MPM) { > > > > addExtensionsToPM(EP_ScalarOptimizerLate, MPM); > > > > + if (Vectorize) { > > + MPM.add(createBBVectorizePass()); > > + if (OptLevel> 1) { > > + MPM.add(createInstructionCombiningPass()); > > + MPM.add(createGVNPass()); // Remove redundancies > > + } &gt...

...minationPass()); // Delete dead stores + PM.add(createAggressiveDCEPass()); // Delete dead instructions + if (UseNewSROA) + PM.add(createSROAPass(/*RequiresDomTree*/ false)); + else + PM.add(createScalarReplAggregatesPass(-1, false)); + + addExtensionsToPM(EP_ScalarOptimizerLate, PM); + + + // Add the various vectorization passes and relevant cleanup passes for + // them since we are no longer in the middle of the main scalar pipeline. + if (/*LoopVectorize && */OptLevel > 1 && SizeLevel < 2) + PM.add(createLoopVectorizePass()...

Tobias, et al., Attached is the my autovectorization pass. I've fixed a bug that appears when using -bb-vectorize-aligned-only, fixed some 80-col violations, etc., and at least on x86_64, all test cases pass except for a few; and all of these failures look like instruction-selection bugs. For example: MultiSource/Applications/ClamAV - fails to compile shared_sha256.c with an error: error 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

Tobias, I've attached the latest version of my autovectorization patch. I was able to add support for using the ScalarEvolution analysis for load/store pairing (thanks for your help!). This led to a modest performance increase and a modest compile-time increase. This version also has a cutoff as you suggested (although the default value is set high (4000 instructions between pairs) because