search for: gesummv

...erimental results are as follows: (benchmarks are collected from Po | | Clang (seconds) | Polly-basic (seconds) | 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% |...

...collected from Po > > | > | Clang > (seconds) | Polly-basic > (seconds) | 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...

...gt;> | Clang >> (seconds) | Polly-basic >> (seconds) | 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% | >&gt...

....1602 0.2002 1.0761 1.3175 2.04% > 27.52% 585.41% 739.17% 3mm.c 0.1529 0.1559 0.1826 0.4134 > 1.0436 1.96% 19.42% 170.37% 582.54% bicg.c 0.1244 0.1268 > 0.1353 0.1977 0.2828 1.93% 8.76% 58.92% 127.33% doitgen.c > 0.1492 0.1505 0.1644 0.3325 0.8971 0.00% 10.19% 122.86% 501.27% > gesummv.c 0.1224 0.1279 0.134 0.1999 0.2937 4.49% 9.48% > 63.32% 139.95% jacobi.c 0.1444 0.1506 0.1592 0.3912 0.8494 > 0.00% 10.25% 170.91% 488.23% seidel.c 0.1337 0.1353 0.1462 > 0.6299 0.9155 0.00% 9.35% 371.13% 584.74% adi.c 0.1593 > 0.1621 0.1835 1.4375 1.849 1.76% 15.19% 802.39% 1060.70...

...9897368| 0|0.446003224| -0.17| 3399897368| 0| |SingleSource/Benchmarks/Polybench/linear-algebra/kernels/gemver/gemver.test | 72|0.476362624| 714917745|0.479692636| -0.69| 714917750| 0|0.475910147| 0.1| 714917746| 0| |SingleSource/Benchmarks/Polybench/linear-algebra/kernels/gesummv/gesummv.test | 146|0.201739334| 480454033|0.201744234| 0| 480454024| 0|0.201747124| 0| 480454027| 0| |SingleSource/Benchmarks/Polybench/linear-algebra/kernels/mvt/mvt.test | 82|0.414533228| 480687267| 0.41015712| 1.07| 480687258| 0| 0.41239746| 0.52| 4806872...

...gt;> | Clang >> (seconds) | Polly-basic >> (seconds) | 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% | >&gt...

Hi all, I have updated my GSoS proposal: "FastPolly: Reducing LLVM-Polly Compiling overhead" (https://gist.github.com/tanstar/5441808). I think the pass ordering problem you discussed early can be also investigated in this project! Is there any comment or advice about my proposal? I appreciate all your help and advice. Thanks, Star Tan Proposal:

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

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

...80 2 0.03 207347 gen.ll 12 112038 0 0.01 112020 0 0.02 112020 genmove.ll 1 16012 0 0.01 15986 0 0.01 15986 genorient.ll 1 179023 0 0.02 178990 0 0.02 178990 gen_php.ll 30 209617 2 0.02 200573 2 0.03 185846 gen_ruby.ll 29 183851 4 0.02 169929 4 0.02 169929 gentwf.ll 1 55799 0 0.01 55766 0 0.01 55766 gesummv.ll 12 24932 0 0.01 24881 0 0.01 24881 getargs.ll 1 8175 0 0.01 8149 0 0.01 8149 get_audio.ll 19 84570 0 0.01 84539 0 0.01 84539 getbits.ll 8 20663 0 0.01 20628 0 0.01 20628 getblk.ll 4 82909 0 0.02 82874 0 0.01 82874 getDeleteCommand.ll 1 21890 0 0.01 21865 0 0.01 21865 getFloat.ll 1 6791 0 0.01 67...