search for: equake

...ssure) with no scheduler (-pre-RA-sched=none), and I got these numbers. The ratio is low_reg_pressure/none, that is, the lower the number, the better the performance with low register pressure: CFP2000/177.mesa/177.mesa 1.00 CFP2000/179.art/179.art 0.98 CFP2000/183.equake/183.equake 1.00 CFP2000/188.ammp/188.ammp 0.98 CINT2000/164.gzip/164.gzip 0.97 CINT2000/175.vpr/175.vpr 0.97 CINT2000/176.gcc/176.gcc n/a // crashed! CINT2000/181.mcf/181.mcf 1.02 CINT2000/186.crafty/186.crafty...

...rom local live range splitting. The register-starved i386 target benefits the most. This is the change in execution time for the SPEC benchmarks that change by more than 3% (minus means faster, plus slower): Targeting i386: -19.3% 164.gzip -12.5% 433.milc -8.8% 473.astar -7.4% 401.bzip2 -6.4% 183.equake -4.9% 456.hmmer -4.6% 186.crafty -4.6% 188.ammp -4.1% 403.gcc -4.0% 256.bzip2 -3.2% 197.parser -3.1% 175.vpr -3.0% 464.h264ref +6.7% 177.mesa With more registers and out-of-order execution hiding the cost of spilling, x86-64 is more mixed. I suspect this architecture is more sensitive to code layo...

...0.00% 0.00% 49.01% -0.81% Povray/povray 0.01% 6.02% 39.36% -2.53% SPEC/CFP2000/177.mesa/177.mesa 0.00% 0.00% 14.90% -1.12% SPEC/CFP2000/179.art/179.art 0.00% 0.00% 19.51% 1.22% SPEC/CFP2000/183.equake/183.equake 0.00% -1.85% 3.54% 0.00% SPEC/CFP2000/188.ammp/188.ammp 0.28% -0.18% 48.68% 3.10% SPEC/CFP2006/433.milc/433.milc 0.00% -0.14% 20.31% 2.68% SPEC/CFP2006/444.namd/444.namd 0.04% 0.44% 3.28% 1.40% SPEC/CFP2006/44...

...his is actually mentioned there. Only, it says to define the LLVM_LIB_SEARCH_PATH environment variable. Only, I can't find libcrtend.a anywhere in the cfrontend directories. Is there a known workaround for this? And if there is, why isn't it in the documentation? Affected benchmarks: equake, lucas, vpr, gcc, crafty, eon, gcc *** syntax error Compiling the perlbmk benchmark produces a syntax error. This may be a GCC4 problem. <path>/SPEC_CPU2000_1.3_src/benchspec/CINT2000/253.perlbmk/src/ nt_perlmain.c:80: error: syntax error before ‘int’ (among others) This specific line...

...e edges are instrumented with a counter (in comparison to 100% with the current edge profiling) *) the performance overhead (on linux-x68_64, other platforms to follow) was 14.76% with the current profiling and 8.20% with the optimal profiling (there are strange effects with the mcf and equake benchmarks where the current edge profiling is as fast as the un-instrumented code whereas the optimally instrumented code has a small (~5%) performance overhead) *) when mcf and equake are excluded the average performance overhead is 51.31% with optimal profiling (in comparison to 100%...

On 31 Aug 2006, at 23:46, Chris Lattner wrote: > On Thu, 31 Aug 2006, Kenneth Hoste wrote: >> Bummer. I think I'll contact the NAG support for more info on >> this. Can you >> show me the content of your Makefile.nagfortran? > > It is identical to yours. > >> Also, it is possible to tell make only to compile benchmark X? How >> can I >>

...6% 6.39% 177.mesa 3612 2752 3597 31.25% 0.42% 570567 590889 561250 -3.44% 1.66% 178.galgel 6637 6809 6617 -2.53% 0.30% 225564 225583 233742 -0.01% -3.50% 179.art 6710 5219 5588 28.57% 20.08% 25111 24188 28126 3.82% -10.72% 183.equake 5247 4813 5118 9.02% 2.52% 32539 34011 31431 -4.33% 3.53% 187.facerec 4332 4072 4380 6.39% -1.10% 82061 84290 85737 -2.64% -4.29% 188.ammp 2632 2424 2677 8.58% -1.68% 155976 155712 161403 0.17% -3.36% 189.lucas 5588 34...

...no additional output (error or warnings) is generated. Also, the execution diff seems to be empty. Additionally, I don't think the programs get executed at all, because make runs too fast. For gap/gcc, only the cbe test fails, the other (including JIT) are ok. Affected benchmarks: galgel, equake, lucas, gcc, gap, facerec, sixtrack, wupwise, mgrid, applu, apsi Since these include both SPECfp and SPECint benchmarks, this has nothing todo with f95. *** 2) *** Undefined references With 3 benchmarks (vpr, crafty and eon), I'm getting similar undefined references: /tmp/ccGCQxYs.o(....

I recently realized that I haven't sent out a status update for the LLVM core components quite a while, so here is a new one: We've been really busy working on LLVM adding all kinds of new features, fixing lots of bugs, and are rapidly converging on our 1.0 release for this August. Here are some of the new features added recently: 1. Support for static constructors/destructors in

...6% 6.39% 177.mesa 3612 2752 3597 31.25% 0.42% 570567 590889 561250 -3.44% 1.66% 178.galgel 6637 6809 6617 -2.53% 0.30% 225564 225583 233742 -0.01% -3.50% 179.art 6710 5219 5588 28.57% 20.08% 25111 24188 28126 3.82% -10.72% 183.equake 5247 4813 5118 9.02% 2.52% 32539 34011 31431 -4.33% 3.53% 187.facerec 4332 4072 4380 6.39% -1.10% 82061 84290 85737 -2.64% -4.29% 188.ammp 2632 2424 2677 8.58% -1.68% 155976 155712 161403 0.17% -3.36% 189.lucas 5588 34...

...ion is that I see more redundant loads not being > >> hoisted out of loops by LICM. > >> > >> Due to license restrictions, I cannot paste SPEC code here, but I > >> think you have access to it. > >> > >> I tried to simplify a top function in equake (quake.c smvp) to show > >> the issue. See the attached reduced test case. > >> > >> If you look at the the source code you will see something like: > >> for { > >> ...load v[i][0]... > >> while { > >> ...load v[i][0]... > >>...

...gt;> > >> hoisted out of loops by LICM. >> > >> >> > >> Due to license restrictions, I cannot paste SPEC code here, but I >> > >> think you have access to it. >> > >> >> > >> I tried to simplify a top function in equake (quake.c smvp) to show >> > >> the issue. See the attached reduced test case. >> > >> >> > >> If you look at the the source code you will see something like: >> > >> for { >> > >> ...load v[i][0]... >> > >> wh...

...r warnings) is > generated. Also, the execution diff seems to be empty. > Additionally, I don't think the programs get executed at all, because > make runs too fast. > > For gap/gcc, only the cbe test fails, the other (including JIT) are ok. > > Affected benchmarks: galgel, equake, lucas, gcc, gap, facerec, > sixtrack, wupwise, mgrid, applu, apsi > > Since these include both SPECfp and SPECint benchmarks, this has > nothing todo with f95. > > *** 2) *** Undefined references > > With 3 benchmarks (vpr, crafty and eon), I'm getting similar > unde...

...ps by LICM. >>>> > >> >>>> > >> Due to license restrictions, I cannot paste SPEC code here, but I >>>> > >> think you have access to it. >>>> > >> >>>> > >> I tried to simplify a top function in equake (quake.c smvp) to show >>>> > >> the issue. See the attached reduced test case. >>>> > >> >>>> > >> If you look at the the source code you will see something like: >>>> > >> for { >>>> > >> ...l...

...; >> >>>>>> > >> Due to license restrictions, I cannot paste SPEC code here, but I >>>>>> > >> think you have access to it. >>>>>> > >> >>>>>> > >> I tried to simplify a top function in equake (quake.c smvp) to show >>>>>> > >> the issue. See the attached reduced test case. >>>>>> > >> >>>>>> > >> If you look at the the source code you will see something like: >>>>>> > >> for { &gt...

...undant loads not being > > >> hoisted out of loops by LICM. > > >> > > >> Due to license restrictions, I cannot paste SPEC code here, but I > > >> think you have access to it. > > >> > > >> I tried to simplify a top function in equake (quake.c smvp) to show > > >> the issue. See the attached reduced test case. > > >> > > >> If you look at the the source code you will see something like: > > >> for { > > >> ...load v[i][0]... > > >> while { > > >>...

...strumented with a counter (in >   comparison to 100% with the current edge profiling) > *) the performance overhead (on linux-x68_64, other platforms to follow) was >   14.76% with the current profiling and 8.20% with the optimal profiling >   (there are strange effects with the mcf and equake benchmarks where the >   current edge profiling is as fast as the un-instrumented code whereas the >   optimally instrumented code has a small (~5%) performance overhead) > *) when mcf and equake are excluded the average performance overhead is >   51.31% with optimal profiling (in comp...

...undant loads not being > > >> hoisted out of loops by LICM. > > >> > > >> Due to license restrictions, I cannot paste SPEC code here, but I > > >> think you have access to it. > > >> > > >> I tried to simplify a top function in equake (quake.c smvp) to show > > >> the issue. See the attached reduced test case. > > >> > > >> If you look at the the source code you will see something like: > > >> for { > > >> ...load v[i][0]... > > >> while { > > >>...

...an Silva > > > * Os * > Benchmark_ID Reference Test Expansion Percent > ------------------------------------------------------------------------------- > External/Nurbs/nurbs 2.3302 2.3122 0.99 -1% > External/SPEC/CFP2000/183.equake/183.eq 3.2606 3.2419 0.99 -1% > External/SPEC/CFP2006/447.dealII/447.de <http://447.de/> 16.4638 16.1313 0.98 -2% > External/SPEC/CFP2006/470.lbm/470.lbm 2.0159 1.9931 0.99 -1% > External/SPEC/CINT2000/164.gzip/164.gzi...

Hi Chandler, Thanks for fixing the problem with the insertps mask. Generally the new shuffle lowering looks promising, however there are some cases where the codegen is now worse causing runtime performance regressions in some of our internal codebase. You have already mentioned how the new shuffle lowering is missing some features; for example, you explicitly said that we currently lack of