search for: 3mm

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

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

...9-02 17:05: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 t...

...s 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, b...

...as 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 g...

...le_time(+350.00%), execution_time(-13.64%) SingleSource/Benchmarks/Stanford/Puzzle, compile_time(+345.45%), execution_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/...

...provement over Cloog. Top 10 improvements are shown as follows: Performance Improvements - Compile Time (ISL over Cloog) MultiSource/Benchmarks/ASC_Sequoia/AMGmk/AMGmk -69.11% MultiSource/Benchmarks/Trimaran/netbench-crc/netbench-crc -44.39% SingleSource/Benchmarks/Polybench/linear-algebra/kernels/3mm/3mm -12.74% SingleSource/Benchmarks/Polybench/linear-algebra/kernels/gemm/gemm -11.21% MultiSource/Benchmarks/TSVC/LoopRerolling-flt/LoopRerolling-flt -11.14% SingleSource/Benchmarks/Polybench/linear-algebra/kernels/syr2k/syr2k -11.11% MultiSource/Benchmarks/TSVC/Packing-flt/Packing-flt -10.87% Mul...

...er} \begin{tabular}{|l||c|c|} \hline \multicolumn{1}{|l||}{\bf tab}&\multicolumn{}{c||}{}&\multicolumn{2}{c|}{\bf v2}\\ \cline{2-3} \multicolumn{1}{|l||}{}&\multicolumn{1}{c|}{val1}&\multicolumn{1}{c|}{val2}\\ \hline val1&1&1\\ val2&0&1\\ \hline \end{tabular} \vspace{3mm} \caption{my table\label{tab}} \end{center} \end{table} and within this code the problem is the second multicolumn (&\multicolumn{}{c||}{}), as it has no number specifying how many columns the multicolumn should cover. Latex (at least my version) complains. When deleting this part of the code,...

...t is based > on runtime alias checks, thus versioning. We are currently fixing the bugs > in the runtime alias check generation we merged yesterday but after that > (or if you like earlier) I can submit the annotation patch for review. > Some limited tests on polybench benchmarks (e.g., 3mm) without any > polyhedral > optimizations, thus only parallel and noalias annotations, showed up to > 20% improvement. > > Best regards, > Johannes > > On 09/19, Samuel F Antao wrote: > > > > > > Hi all, > > > > In LLVM language reference I re...

...oad (econd) | Polly-optimize (econd) | Polly-load penalty | Polly-optimize Penalty | | 2mm.c | 0.155 | 0.158 | 0.75 | 1.9% | 383.9% | | correlation.c | 0.132 | 0.133 | 0.319 | 0.8% | 141.7% | | geummv.c | 0.152 | 0.157 | 0.794 | 3.3% | 422.4% | | ludcmp.c | 0.157 | 0.159 | 0.391 | 1.3% | 149.0% | | 3mm.c | 0.103 | 0.109 | 0.122 | 5.8% | 18.4% | | covariance.c | 0.16 | 0.163 | 1.346 | 1.9% | 741.3% | | gramchmidt.c | 0.159 | 0.167 | 1.023 | 5.0% | 543.4% | | eidel.c | 0.125 | 0.13 | 0.285 | 4.0% | 128.0% | | adi.c | 0.155 | 0.156 | 0.953 | 0.6% | 514.8% | | doitgen.c | 0.124 | 0.128 | 0.298 | 3.2%...

Hi all, In LLVM language reference I read that one can use noalias and alias.scope metadata to provide more detailed information about pointer aliasing. However, I was unable to obtain any LLVM IR annotations using this metadata from any LLVM optimization pass or Clang frontend (am I missing something?). If I understand it correctly, this information would complement the type-based alias

...ad | Polly-optimize >> overhead | >> | 2mm.c | 0.786 | 0.802 | 1.944 | 2.0% | 147.3% | >> | correlation.c | 0.782 | 0.792 | 2.005 | 1.3% | 156.4% | >> | gesummv.c | 0.583 | 0.603 | 1.08 | 3.4% | 85.2% | >> | ludcmp.c | 0.787 | 0.806 | 2.475 | 2.4% | 214.5% | >> | 3mm.c | 0.786 | 0.811 | 2.617 | 3.2% | 233.0% | >> | covariance.c | 0.73 | 0.74 | 2.294 | 1.4% | 214.2% | >> | gramschmidt.c | 0.63 | 0.643 | 1.134 | 2.1% | 80.0% | >> | seidel.c | 0.632 | 0.645 | 2.036 | 2.1% | 222.2% | >> | adi.c | 0.8 | 0.811 | 3.044 | 1.4% | 280.5% | >&gt...

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 =

...econds) | Polly-optimize (seconds) | Polly-load overhead | Polly-optimize overhead | | 2mm.c | 0.786 | 0.802 | 1.944 | 2.0% | 147.3% | | correlation.c | 0.782 | 0.792 | 2.005 | 1.3% | 156.4% | | gesummv.c | 0.583 | 0.603 | 1.08 | 3.4% | 85.2% | | ludcmp.c | 0.787 | 0.806 | 2.475 | 2.4% | 214.5% | | 3mm.c | 0.786 | 0.811 | 2.617 | 3.2% | 233.0% | | covariance.c | 0.73 | 0.74 | 2.294 | 1.4% | 214.2% | | gramschmidt.c | 0.63 | 0.643 | 1.134 | 2.1% | 80.0% | | seidel.c | 0.632 | 0.645 | 2.036 | 2.1% | 222.2% | | adi.c | 0.8 | 0.811 | 3.044 | 1.4% | 280.5% | | doitgen.c | 0.742 | 0.752 | 2.32 | 1.3% |...

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

Hey Y'all, Does CentOS have a desk top switcher similar to what you find on Fedora? A friend of mine want's to be able to switch between desktops. I've only got Gnome installed on my machine so I don't switch. A search of Google turns up reference to CentOS 4 for desktop switcher but I don't see anything for CentOS 6.3.

Hi, I have just tagged 3.7.1-rc1, so it is ready for testing. As a reminder, when doing regression testing, use the 3.7.0 release as your baseline. Thanks, Tom

...nds) | Polly-load overhead | Polly-optimize > overhead | > | 2mm.c | 0.786 | 0.802 | 1.944 | 2.0% | 147.3% | > | correlation.c | 0.782 | 0.792 | 2.005 | 1.3% | 156.4% | > | gesummv.c | 0.583 | 0.603 | 1.08 | 3.4% | 85.2% | > | ludcmp.c | 0.787 | 0.806 | 2.475 | 2.4% | 214.5% | > | 3mm.c | 0.786 | 0.811 | 2.617 | 3.2% | 233.0% | > | covariance.c | 0.73 | 0.74 | 2.294 | 1.4% | 214.2% | > | gramschmidt.c | 0.63 | 0.643 | 1.134 | 2.1% | 80.0% | > | seidel.c | 0.632 | 0.645 | 2.036 | 2.1% | 222.2% | > | adi.c | 0.8 | 0.811 | 3.044 | 1.4% | 280.5% | > | doitgen.c | 0.74...

...econd) | Polly-load penalty | Polly-optimize > Penalty | > | 2mm.c | 0.155 | 0.158 | 0.75 | 1.9% | 383.9% | > | correlation.c | 0.132 | 0.133 | 0.319 | 0.8% | 141.7% | > | geummv.c | 0.152 | 0.157 | 0.794 | 3.3% | 422.4% | > | ludcmp.c | 0.157 | 0.159 | 0.391 | 1.3% | 149.0% | > | 3mm.c | 0.103 | 0.109 | 0.122 | 5.8% | 18.4% | > | covariance.c | 0.16 | 0.163 | 1.346 | 1.9% | 741.3% | This is a very large slowdown. On my system I get 0.06 sec for Polly-load 0.09 sec for Polly-optimize What exact version of Polybench did you use? What compiler flags did you use to compile th...

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