similar to: [LLVMdev] [polly] pass ordering

On 04/17/2013 05:53 PM, Sebastian Pop wrote: > Hi, > > polly is run very early and schedules the following passes before it runs: > > /// @brief Schedule a set of canonicalization passes to prepare for Polly > /// > /// The set of optimization passes was partially taken/copied from the > /// set of default optimization passes in LLVM. It is used to bring the code > ///

Tobias Grosser wrote: > On 04/17/2013 05:53 PM, Sebastian Pop wrote: > >Hi, > > > >polly is run very early and schedules the following passes before it runs: > > > >/// @brief Schedule a set of canonicalization passes to prepare for Polly > >/// > >/// The set of optimization passes was partially taken/copied from the > >/// set of default

At 2013-09-09 13:07:07,"Tobias Grosser" <tobias at grosser.es> wrote: >On 09/09/2013 05:18 AM, Star Tan wrote: >> >> At 2013-09-09 05:52:35,"Tobias Grosser" <tobias at grosser.es> wrote: >> >>> On 09/08/2013 08:03 PM, Star Tan wrote: >>> Also, I wonder if your runs include the dependence analysis. If this is >>> the

Hello all, I have evaluated the compile-time and execution-time performance of Polly canonicalization passes. Details can be referred to http://188.40.87.11:8000/db_default/v4/nts/recent_activity. There are four runs: pollyBasic (run 45): clang -O3 -Xclang -load -Xclang LLVMPolly.so pollyNoGenSCEV (run 44): clang -O3 -Xclang -load -Xclang LLVMPolly.so -mllvm -polly -mllvm -polly-codegen-scev

On 04/17/2013 08:37 PM, Sebastian Pop wrote: > Tobias Grosser wrote: >> On 04/17/2013 05:53 PM, Sebastian Pop wrote: >>> Hi, >>> >>> polly is run very early and schedules the following passes before it runs: >>> >>> /// @brief Schedule a set of canonicalization passes to prepare for Polly >>> /// >>> /// The set of

----- Original Message ----- > From: "Tobias Grosser" <tobias at grosser.es> > To: "Sebastian Pop" <spop at codeaurora.org> > Cc: llvmdev at cs.uiuc.edu > Sent: Wednesday, April 17, 2013 12:45:26 PM > Subject: Re: [LLVMdev] [polly] pass ordering > > On 04/17/2013 05:53 PM, Sebastian Pop wrote: > > Hi, > > > > polly is run very

On 09/09/2013 05:18 AM, Star Tan wrote: > > At 2013-09-09 05:52:35,"Tobias Grosser" <tobias at grosser.es> wrote: > >> On 09/08/2013 08:03 PM, Star Tan wrote: >> Also, I wonder if your runs include the dependence analysis. If this is >> the case, the numbers are very good. Otherwise, 30% overhead seems still >> to be a little bit much. > I think

Tobias Grosser wrote: > As said before, we could probably add it in between those two passes: > > MPM.add(createReassociatePass()); // Reassociate expressions > + addExtensionsToPM(EP_LoopOptimizerStart, MPM); > MPM.add(createLoopRotatePass()); // Rotate Loop As this is in the middle of other LNO passes, can you please rename s/EP_LoopOptimizerStart/EP_Polly_LNO/ or

On 04/17/2013 09:04 PM, Sebastian Pop wrote: > Tobias Grosser wrote: >> As said before, we could probably add it in between those two passes: >> >> MPM.add(createReassociatePass()); // Reassociate expressions >> + addExtensionsToPM(EP_LoopOptimizerStart, MPM); >> MPM.add(createLoopRotatePass()); // Rotate Loop > > As this is in the middle of other

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

At 2013-09-09 05:52:35,"Tobias Grosser" <tobias at grosser.es> wrote: >On 09/08/2013 08:03 PM, Star Tan wrote: >> Hello all, >> >> >> I have done some basic experiments about Polly canonicalization passes and I found the SCEV canonicalization has significant impact on both compile-time and execution-time performance. > >Interesting. > >>

Hi Tobias, At 2013-09-19 22:59:25,"Tobias Grosser" <tobias at grosser.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, >>

Here is an update about moving Polly later. 1. Why does Polly generate incorrect code when we move Polly immediately after the loop rotating pass? It is mainly caused by a wrong polly merge block. When Polly detects a valid loop for Polyhedral transformations, it usually introduces a new basic block "polly.merge_new_and_old" after the original loop exit block. This new basic block

On 09/25/2013 04:55 AM, Star Tan wrote: > Here is an update about moving Polly later. Hi star tan, thanks for your report. > > 1. Why does Polly generate incorrect code when we move Polly immediately after the loop rotating pass? > > It is mainly caused by a wrong polly merge block. When Polly detects a valid loop for Polyhedral transformations, it usually introduces a new basic

Hi Duncan & Tobi, Thanks a lot for your interest, and for pointing out differences in GIMPLE I missed. Attached is simplified test case. Is it good? Tobi, regarding runtime alias analysis: in KernelGen we already do it along with runtime values substitution. For example: <------------------ __kernelgen_main_loop_17: compile started ---------------------> Integer args substituted:

On 01/01/2013 02:45 PM, Duncan Sands wrote: > Hi Dmitry, > >> >> In our compiler we use a modified version LLVM Polly, which is very >> sensitive to >> proper code generation. Among the number of limitations, the loop region >> (enclosed by phi node on induction variable and branch) is required to >> be free >> of additional memory-dependent

Hi all, It seems that Polly could still speed up test-suite/SingleSource/Benchmarks/CoyoteBench/huffbench.c even without any optimization and code generation. Our evaluation show that when compiled with "clang -Xclang -load -Xclang LLVMPolly.so -mllvm -polly -mllvm -polly-optimizer=none -mllvm -polly-code-generator=none", the execution time of huffbench would reduced to 15 secs from

On 08/05/2013 08:08 PM, Star Tan wrote: > Hi all, > > > It seems that Polly could still speed up test-suite/SingleSource/Benchmarks/CoyoteBench/huffbench.c even without any optimization and code generation. Our evaluation show that when compiled with "clang -Xclang -load -Xclang LLVMPolly.so -mllvm -polly -mllvm -polly-optimizer=none -mllvm -polly-code-generator=none", the

Hello all, I have done some basic experiments about Polly canonicalization passes and I found the SCEV canonicalization has significant impact on both compile-time and execution-time performance. Detailed results for SCEV and default canonicalization can be viewed on: http://188.40.87.11:8000/db_default/v4/nts/32 (or 33, 34) *pNoGen with SCEV canonicalization (run 32): -O3 -Xclang -load

On 09/08/2013 08:03 PM, Star Tan wrote: > Hello all, > > > I have done some basic experiments about Polly canonicalization passes and I found the SCEV canonicalization has significant impact on both compile-time and execution-time performance. Interesting. > Detailed results for SCEV and default canonicalization can be viewed on: http://188.40.87.11:8000/db_default/v4/nts/32 (or