search for: syrk

...xecution_time(-40.91%) SingleSource/Benchmarks/Polybench/linear-algebra/kernels/2mm/2mm, compile_time(+278.95%), execution_time(0%) SingleSource/Benchmarks/Polybench/linear-algebra/kernels/3mm/3mm, compile_time(+270.73%), execution_time(0%) SingleSource/Benchmarks/Polybench/linear-algebra/kernels/syrk/syrk, compile_time(+208.57%), execution_time(0%) SingleSource/Benchmarks/Polybench/linear-algebra/kernels/gemm/gemm, compile_time(+202.63%), execution_time(0%) SingleSource/Regression/C/test_indvars, compile_time(+200.00%), execution_time(0%) Results show that some Polly leads to significant co...

Hi all, It seems that Polly's code generation can leads to high compile-time overhead, especially for PolyBench applications such as 2mm, 3mm, gemm, syrk, etc. Some basic evaluation and analysis for Polly's code generation can be referred to http://llvm.org/bugs/show_bug.cgi?id=16898. Currently, we can choose to run -polly-code-generator=cloog or -polly-code-generator=isl for code generation, but both of them lead to almost double compile-ti...

On 09/01/2013 08:02 PM, Star Tan wrote: > Hi all, > > > It seems that Polly's code generation can leads to high compile-time overhead, especially for PolyBench applications such as 2mm, 3mm, gemm, syrk, etc. Some basic evaluation and analysis for Polly's code generation can be referred to http://llvm.org/bugs/show_bug.cgi?id=16898. > > > Currently, we can choose to run -polly-code-generator=cloog or -polly-code-generator=isl for code generation, but both of them lead to almost doubl...

...52,"Tobias Grosser" <tobias at grosser.es> wrote: >On 09/01/2013 08:02 PM, Star Tan wrote: >> Hi all, >> >> >> It seems that Polly's code generation can leads to high compile-time overhead, especially for PolyBench applications such as 2mm, 3mm, gemm, syrk, etc. Some basic evaluation and analysis for Polly's code generation can be referred to http://llvm.org/bugs/show_bug.cgi?id=16898. >> >> >> Currently, we can choose to run -polly-code-generator=cloog or -polly-code-generator=isl for code generation, but both of them lead to...

On 08/10/2013 06:59 PM, Star Tan wrote: > Hi all, > > I have evaluated Polly's performance on LLVM test-suite with latest LLVM (r188054) and Polly (r187981). Results can be viewed on: http://188.40.87.11:8000. Hi Star Tan, thanks for the update. > There are mainly five new tests and each test is run with 10 samples: > clang (run id = 27): clang -O3 > pollyBasic (run id =

...uot; <tobias at grosser.es> wrote: > >> On 09/01/2013 08:02 PM, Star Tan wrote: >>> Hi all, >>> >>> >>> It seems that Polly's code generation can leads to high compile-time overhead, especially for PolyBench applications such as 2mm, 3mm, gemm, syrk, etc. Some basic evaluation and analysis for Polly's code generation can be referred to http://llvm.org/bugs/show_bug.cgi?id=16898. >>> >>> >>> Currently, we can choose to run -polly-code-generator=cloog or -polly-code-generator=isl for code generation, but both of t...

...er.es> wrote: >> >>> On 09/01/2013 08:02 PM, Star Tan wrote: >>>> Hi all, >>>> >>>> >>>> It seems that Polly's code generation can leads to high compile-time overhead, especially for PolyBench applications such as 2mm, 3mm, gemm, syrk, etc. Some basic evaluation and analysis for Polly's code generation can be referred to http://llvm.org/bugs/show_bug.cgi?id=16898. >>>> >>>> >>>> Currently, we can choose to run -polly-code-generator=cloog or -polly-code-generator=isl for code generation, b...

Hi all, I have evaluated Polly's performance on LLVM test-suite with latest LLVM (r188054) and Polly (r187981).  Results can be viewed on: http://188.40.87.11:8000. There are mainly five new tests and each test is run with 10 samples: clang (run id = 27):  clang -O3 pollyBasic (run id = 28):  clang -O3 -load LLVMPolly.so pollyNoGen (run id = 29):  pollycc -O3 -mllvm -polly-optimizer=none

Hi all, I've started looking at the GlobalMerge pass, enabled by default on ARM and AArch64. I think we should reconsider that, at least for AArch64. As is, the pass just merges all globals together, in groups of 4KB (AArch64, 128B on ARM). At the time it was enabled, the general thinking was "it's almost free, it doesn't affect performance much, we might as well use it".

...3527704| 0| 20.0699099| 0.34|11903527697| 0| |SingleSource/Benchmarks/Polybench/linear-algebra/kernels/syr2k/syr2k.test | 40|3.707457334|28020923169|3.697747398| 0.26|28020923166| 0|3.703755898| 0.1|28020923169| 0| |SingleSource/Benchmarks/Polybench/linear-algebra/kernels/syrk/syrk.test | 40|1.709082542|14059124595|1.711252681| -0.13|14059124600| 0|1.711381977| -0.13|14059124601| 0| |SingleSource/Benchmarks/Polybench/linear-algebra/kernels/trisolv/trisolv.test | 225|0.103904759| 216435815|0.104026252| -0.12| 216435811| 0|0.104078778| -0.17| 2164...

Hi Stepan, Sorry for the delay. It's great that you are working on MergeFunctions as well and I agree, we should definitely try to combine our efforts to improve MergeFunctions. Just to give you some context, the pass (with the similar function merging patch) is already being used in a production setting. From my point of view, it would be better if we focus on improving its capability

...846 0 0.06 617812 0 0.06 617812 symbol.ll 10 28263 0 0.01 28234 0 0.01 28521 symm.ll 12 28959 0 0.01 28911 0 0.01 28911 sym_tab.ll 3 9832 0 0.01 9802 0 0.01 9802 symtab.ll 5 13680 0 0.01 13654 0 0.01 13654 Synchronization.ll 2 8448 0 0.01 8420 0 0.01 8420 syr2k.ll 12 29029 0 0.01 28980 0 0.01 28980 syrk.ll 12 25741 0 0.01 25693 0 0.01 25693 sysspec.ll 13 18074 0 0.01 18058 0 0.01 18058 System.ll 2 951 0 0.01 923 0 0.01 923 systems.ll 4 21729 0 0.01 21694 0 0.01 21694 t0.ll 0 3318 0 0.01 3289 0 0.01 3289 t1.ll 5 13744 0 0.01 13715 0 0.01 13715 t2.ll 1 1804 0 0.01 1775 0 0.01 1775 t3.ll 3 25197 0 0....