search for: almabench

Hello, I was trying to compare the performance of icc, gcc and llvm on the program almabench.c in Coyote Benchmark suite. Here is a line of code from the program. da = da + (ca[np][k] * cos(arga) + sa[np][k] * sin(arga)) * 0.0000001; gcc and icc are performing way better than llvm as they are using 'sincos' library function to compute the sin and the cos of the argument in a...

Hi Suresh, > I was trying to compare the performance of icc, gcc and llvm on the > program almabench.c in Coyote Benchmark suite. Here is a line of code > from the program. > > > da = da + (ca[np][k] * cos(arga) + sa[np][k] * sin(arga)) * 0.0000001; > > gcc and icc are performing way better than llvm as they are using > 'sincos' library function to compute the sin...

Hi, Sorry for the late report but I've only just found these issues. Llvm.org isn't working for me at the moment but I'll file tickets once it is. The issues are: 1. Almabench has some significant numerical differences and fails the reference check for some configs. I'm investigating this one at the moment but early indications are that it's a similar (but different) problem to the one we had in LLVM 3.6.2. 2. Read-only exception tables have broken compati...

I believe I've identified the problem with almabench but I haven't found the root cause in the compiler yet. The problem is that a caller saved register ($f14) is being moved across a call and this call sometimes clobbers the value. As a result, the value of the TWOPI constant used in the fmod() calls isn't always 2*PI. According to -print-...

Dear testers, 3.7.0-rc2 was just tagged. Please test, build binaries, upload to the sftp, and report results to this thread. A lot of fixes have been applied since rc1, both to the build script and the code in general, so hopefully it will be less bumpy this time. >From this point, I will no longer accept merge requests to finish existing features; it's now bug-fixes only. Thanks again

...t; performance on these benchmarks. I don't know if this is due to the > nature of the processor, or if GCC can't take advantage of > processor-specific instructions. I have double-checked my results; > adding -mfpmath=sse (or any of its variants, or -msse) to a compile of > almabench does not make the code run any faster. The only ia32-specific > option that showed consistent value was -momit-leaf-frame-pointer. > > The genetic algorithm was able to find sets of flags that produced > faster code than that emitted by the default -O1, -O2, and -O3 options > (wi...

...ce on these benchmarks. I don't know if this is due to the >> nature of the processor, or if GCC can't take advantage of >> processor-specific instructions. I have double-checked my results; >> adding -mfpmath=sse (or any of its variants, or -msse) to a compile of >> almabench does not make the code run any faster. The only >> ia32-specific >> option that showed consistent value was -momit-leaf-frame-pointer. >> >> The genetic algorithm was able to find sets of flags that produced >> faster code than that emitted by the default -O1, -O2, an...

...emory consumption clobbered registers are handled with RegisterMask machine operands which contain a bitset of all registers clobbered. - Matthias > On Jul 29, 2015, at 3:00 PM, Daniel Sanders <daniel.sanders at imgtec.com> wrote: > > I believe I've identified the problem with almabench but I haven't found the root cause in the compiler yet. > > The problem is that a caller saved register ($f14) is being moved across a call and this call sometimes clobbers the value. As a result, the value of the TWOPI constant used in the fmod() calls isn't always 2*PI. > >...

...ultiSource/Benchmarks/Bullet/bullet.compile 1.26% 45.2907 45.8608 0.0695 > External/SPEC/CINT2006/483_xalancbmk/483_xalancbmk.compile 1.25% 223.7703 > 226.5641 0.1639 > External/SPEC/CFP2006/450_soplex/450_soplex.compile 1.04% 30.5935 30.9124 0.0283 > SingleSource/Benchmarks/CoyoteBench/almabench.exec 1.00% 12.0546 12.1754 0.0049 > > Performance Improvements Δ Previous Current σ > SingleSource/Benchmarks/Misc/fbench.exec -8.84% 2.0834 1.8992 0.0050 > External/SPEC/CINT2006/400_perlbench/400_perlbench.exec -5.17% 9.5375 9.0445 0.0241 > External/SPEC/CINT2006/456_hmmer/456_hm...

...registers are handled with RegisterMask machine operands which contain a bitset of all registers clobbered. - Matthias On Jul 29, 2015, at 3:00 PM, Daniel Sanders <daniel.sanders at imgtec.com<mailto:daniel.sanders at imgtec.com>> wrote: I believe I've identified the problem with almabench but I haven't found the root cause in the compiler yet. The problem is that a caller saved register ($f14) is being moved across a call and this call sometimes clobbers the value. As a result, the value of the TWOPI constant used in the fmod() calls isn't always 2*PI. According to -print-...

...a look at these problems. What is the most important? As to the issue #3 - do we need to keep compatibility with the old mips-mti-linux-gnu toolchain layout? Simon On Wed, Jul 29, 2015 at 1:08 PM, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote: > The issues are: > > 1. Almabench has some significant numerical differences and fails the > reference check for some configs. I'm investigating this one at the moment > but early indications are that it's a similar (but different) problem to the > one we had in LLVM 3.6.2. > > 2. Read-only exception ta...

...marks/Bullet/bullet.compile 1.26% 45.2907 45.8608 0.0695 >> External/SPEC/CINT2006/483_xalancbmk/483_xalancbmk.compile 1.25% 223.7703 >> 226.5641 0.1639 >> External/SPEC/CFP2006/450_soplex/450_soplex.compile 1.04% 30.5935 30.9124 0.0283 >> SingleSource/Benchmarks/CoyoteBench/almabench.exec 1.00% 12.0546 12.1754 0.0049 >> >> Performance Improvements Δ Previous Current σ >> SingleSource/Benchmarks/Misc/fbench.exec -8.84% 2.0834 1.8992 0.0050 >> External/SPEC/CINT2006/400_perlbench/400_perlbench.exec -5.17% 9.5375 9.0445 0.0241 >> External/SPEC/CINT...

...> > As to the issue #3 - do we need to keep compatibility with the old > mips-mti-linux-gnu toolchain layout? > > Simon > > On Wed, Jul 29, 2015 at 1:08 PM, Daniel Sanders > <Daniel.Sanders at imgtec.com> wrote: > > The issues are: > > > > 1. Almabench has some significant numerical differences and fails the > > reference check for some configs. I'm investigating this one at the moment > > but early indications are that it's a similar (but different) problem to the > > one we had in LLVM 3.6.2. > > > > 2....

...ks. I don't know if this is due to the > >> nature of the processor, or if GCC can't take advantage of > >> processor-specific instructions. I have double-checked my results; > >> adding -mfpmath=sse (or any of its variants, or -msse) to a compile of > >> almabench does not make the code run any faster. The only > >> ia32-specific > >> option that showed consistent value was -momit-leaf-frame-pointer. > >> > >> The genetic algorithm was able to find sets of flags that produced > >> faster code than that emitted by...

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

tl;dr in low data situations we don’t look at past information, and that increases the false positive regression rate. We should look at the possibly incorrect recent past runs to fix that. Motivation: LNT’s current regression detection system has false positive rate that is too high to make it useful. With test suites as large as the llvm “test-suite” a single report will show hundreds of

...this program) nts.SingleSource/Benchmarks/Polybench/linear-algebra/kernels/symm/symm.exec > 3. 21.60% cumulative (2.77% - 160.02s this program) nts.MultiSource/Benchmarks/mafft/pairlocalalign.exec > 4. 24.01% cumulative (2.41% - 138.98s this program) nts.SingleSource/Benchmarks/CoyoteBench/almabench.exec > 5. 26.32% cumulative (2.32% - 133.59s this program) nts.MultiSource/Applications/lua/lua.exec > 6. 28.26% cumulative (1.94% - 111.80s this program) nts.MultiSource/Benchmarks/ASC_Sequoia/IRSmk/IRSmk.exec > 7. 30.11% cumulative (1.85% - 106.56s this program) nts.MultiSource/Benchm...

.../Benchmarks/CoyoteBench/huffbench | * | * | SingleSource/Benchmarks/CoyoteBench/fftbench | * | * | SingleSource/Benchmarks/CoyoteBench/lpbench | * | * | SingleSource/Benchmarks/CoyoteBench/almabench | * | * | SingleSource/Benchmarks/McGill/misr | * | * | SingleSource/Benchmarks/McGill/chomp | * | * | SingleSource/Benchmarks/McGill/exptree...

...12.33 | 0.80 1.08 n/a n/a MultiSource/Benchmarks/tramp3d-v4/tramp3d-v4 | 17.1437 3106240 * * * | 3087.78 * * * * | n/a n/a n/a n/a SingleSource/Benchmarks/CoyoteBench/almabench | 0.0213 11396 0.0294 * 0.0287 | 38.31 36.35 28.09 * 27.65 | 1.05 1.36 n/a n/a SingleSource/Benchmarks/CoyoteBench/fftbench | 0.1059 21900 0.0889 * 0.0805...

...16.82 | 0.89 1.24 n/a n/a MultiSource/Benchmarks/tramp3d-v4/tramp3d-v4 | 24.6495 3434392 12.9488 * 11.6887 | 42.76 59.15 65.26 * 76.23 | 0.72 0.66 n/a n/a SingleSource/Benchmarks/CoyoteBench/almabench | 0.0240 11080 0.0280 * 0.0280 | 46.08 42.91 43.76 * 42.42 | 1.07 1.05 n/a n/a SingleSource/Benchmarks/CoyoteBench/fftbench | 0.1320 22880 0.1120 * 0.0960...