search for: fftbench

Many of you are probably wondering about the status of the 2.3 release. Unfortunately, this release has been very difficult and the list of regressions very high. The list has finally dwindled down to the following regressions: Linux/x86: SingleSource/Benchmarks/CoyoteBench/fftbench [ JIT Codegen, JIT] MultiSource/Applications/minisat/minisat [CBE] Darwin/x86: External/SPEC/CINT2006/403.gcc/403.gcc [CBE, but works on mainline..] Darwin/ppc: SingleSource/Benchmarks/CoyoteBench/fftbench [ CBE ] External/SPEC/CINT2006/403.gcc/403.gcc [ CBE] If anyone would like to volunteer to...

...source/Benchmarks/tramp3d-v4/tramp3d-v4: -195.05% (22.2893 => 65.7641) > CBE: > singlesource/Benchmarks/Adobe-C++/loop_unroll: 10.56% (3.22 => 2.88) > singlesource/Benchmarks/Adobe-C++/simple_types_constant_folding: 69.10% (9.71 => 3.00) > singlesource/Benchmarks/CoyoteBench/fftbench: -382.67% (0.75 => 3.62) > singlesource/Benchmarks/Misc-C++/sphereflake: 18.66% (11.90 => 9.68) > singlesource/Benchmarks/Misc-C++/stepanov_container: -1811.11% (0.54 => 10.32) > singlesource/Benchmarks/Misc-C++/stepanov_v1p2: 16.90% (25.33 => 21.05) > singlesource/Bench...

Hi Chris, > Can you check to see if the stepanov_container/fftbench regressions > are real? If so, it would be very interesting to know what is "going > wrong" on them. I think these may not be real. This version of llvm-gcc was built with checking enabled - does this turn on checking in libstdc++? It seems that a bunch of linkonce libstdc++...

...of you are probably wondering about the status of the 2.3 > release. Unfortunately, this release has been very difficult and the > list of regressions very high. The list has finally dwindled down to > the following regressions: > > Linux/x86: > SingleSource/Benchmarks/CoyoteBench/fftbench [ JIT Codegen, JIT] Increasing ulimit to 230 Mb (from 200Mb) makes fftbench/JIT pass on mainline. Maybe JIT should have a higher ulimit because it needs to keep the bytecode in memory too? > MultiSource/Applications/minisat/minisat [CBE] CBE didn't fail for me with the prerelease package...

...Duncan, thank you for working on this! From the LLC tests, I see: > LLC: > singlesource/Benchmarks/Adobe-C++/loop_unroll: 14.13% (3.75 => 3.22) > singlesource/Benchmarks/Adobe-C++/simple_types_constant_folding: > 69.51% (6.92 => 2.11) > singlesource/Benchmarks/CoyoteBench/fftbench: -563.16% (0.57 => 3.78) > singlesource/Benchmarks/Misc-C++/ray: 6.45% (7.60 => 7.11) > singlesource/Benchmarks/Misc-C++/sphereflake: 12.32% (6.09 => 5.34) > singlesource/Benchmarks/Misc-C++/stepanov_container: -2438.89% (0.36 > => 9.14) > singlesource/Benchmarks/Misc/f...

...are probably wondering about the status of the 2.3 > release. Unfortunately, this release has been very difficult and > the list of regressions very high. The list has finally dwindled > down to the following regressions: > > Linux/x86: > SingleSource/Benchmarks/CoyoteBench/fftbench [ JIT Codegen, JIT] > MultiSource/Applications/minisat/minisat [CBE] > Both of these are now fixed! > Darwin/x86: > External/SPEC/CINT2006/403.gcc/403.gcc [CBE, but works on mainline..] > This is a gcc bug, so we are ignoring it for the release. > Darwin/ppc: > SingleSource...

On Jun 2, 2008, at 11:11 PM, Tanya Lattner wrote: > Darwin/ppc: > SingleSource/Benchmarks/CoyoteBench/fftbench [ CBE ] > From what I can see comparing 2.3 with TOT, the "cexp" function is declared like this in 2.3: declare i128 @cexp({double, double}* byval) nounwind It used to be this: declare void @cexp({double, double}* noalias sret, {double, double}* byval) nounwind Does this dif...

...e/Regression/C++/BuiltinTypeInfo cbe /SingleSource/Regression/C++/BuiltinTypeInfo llc /SingleSource/Regression/C++/ofstream_ctor cbe /SingleSource/Regression/C++/ofstream_ctor ^^ All of these fail due to C++ exception handling not implemented in llvm-gcc4 llc /SingleSource/Benchmarks/CoyoteBench/fftbench jit /SingleSource/Benchmarks/CoyoteBench/fftbench ^^ PR990 llc /SingleSource/Benchmarks/Shootout-C++/except jit /SingleSource/Benchmarks/Shootout-C++/except cbe /SingleSource/Benchmarks/Shootout-C++/except llc /SingleSource/Benchmarks/Misc-C++/bigfib jit /SingleSource/Benchmarks/Misc-C++/bigfib...

...probably wondering about the status of the 2.3 > release. Unfortunately, this release has been very difficult and the > list of regressions very high. The list has finally dwindled down to > the following regressions: > ... > Darwin/ppc: > SingleSource/Benchmarks/CoyoteBench/fftbench [ CBE ] For my test run, it looks like the type "llvmUInt128" isn't defined. Is this this the error that you're seeing? > External/SPEC/CINT2006/403.gcc/403.gcc [ CBE] > -bw

I created the 1.9 release branch last night. As a reminder, please do not check in any code changes to the release branch. Please send me email if you have changes that need to be merged into the release branch. To check out the release branch: cvs -d <CVS Repository> co -r release_19 llvm cvs -d <CVS Repository> co -r release_19 llvm-test cvs -d <CVS Repository> co -r

...le /SingleSource/UnitTests/2006-01-23-UnionInit > TEST-FAIL: llc /SingleSource/UnitTests/2006-01-23-UnionInit > TEST-FAIL: jit /SingleSource/UnitTests/2006-01-23-UnionInit > TEST-FAIL: cbe /SingleSource/UnitTests/2006-01-23-UnionInit > TEST-FAIL: llc /SingleSource/Benchmarks/CoyoteBench/fftbench > TEST-FAIL: jit /SingleSource/Benchmarks/CoyoteBench/fftbench > TEST-FAIL: cbe /SingleSource/Benchmarks/CoyoteBench/fftbench > TEST-FAIL: llc /SingleSource/Benchmarks/Shootout-C++/ackermann > TEST-FAIL: jit /SingleSource/Benchmarks/Shootout-C++/ackermann > TEST-FAIL: cbe /SingleSour...

...eld TEST-FAIL: compile /SingleSource/UnitTests/2006-01-23-UnionInit TEST-FAIL: llc /SingleSource/UnitTests/2006-01-23-UnionInit TEST-FAIL: jit /SingleSource/UnitTests/2006-01-23-UnionInit TEST-FAIL: cbe /SingleSource/UnitTests/2006-01-23-UnionInit TEST-FAIL: llc /SingleSource/Benchmarks/CoyoteBench/fftbench TEST-FAIL: jit /SingleSource/Benchmarks/CoyoteBench/fftbench TEST-FAIL: cbe /SingleSource/Benchmarks/CoyoteBench/fftbench TEST-FAIL: llc /SingleSource/Benchmarks/Shootout-C++/ackermann TEST-FAIL: jit /SingleSource/Benchmarks/Shootout-C++/ackermann TEST-FAIL: cbe /SingleSource/Benchmarks/Shootout-C+...

...-dbl -2.93% 2.9336 2.8477 0.0037 MultiSource/Benchmarks/VersaBench/beamformer/beamformer -2.79% 0.8845 0.8598 0.0026 SingleSource/Benchmarks/Misc-C++/Large/sphereflake -2.79% 1.8517 1.8001 0.0014 External/SPEC/CFP2000/177_mesa/177_mesa -2.15% 1.7214 1.6844 0.0017 SingleSource/Benchmarks/CoyoteBench/fftbench -2.05% 0.7280 0.7131 0.0049 MultiSource/Benchmarks/TSVC/NodeSplitting-dbl/NodeSplitting-dbl -1.96% 3.1494 3.0878 0.0034 SingleSource/Benchmarks/Misc/oourafft -1.70% 3.4625 3.4035 0.0009 SingleSource/Benchmarks/Misc/flops -1.31% 7.0775 6.9845 0.0014 MultiSource/Applications/JM/lencod/lencod -1.12% 4...

LLVMers, The LLVM 1.9 Prerelease is available for testing: http://llvm.org/prereleases/1.9/ If anyone can spare some time, please download the appropriate tarballs for your platform and test the release (at least with make check). I'd also appreciate any documentation reviews. Please note that llvm-gcc3 on x86 may not have a clean dejagnu run. You should see one XPASS for

...-2.93%2.93362.84770.0037 > MultiSource/Benchmarks/VersaBench/beamformer/beamformer-2.79%0.88450.8598 > 0.0026SingleSource/Benchmarks/Misc-C++/Large/sphereflake-2.79%1.85171.8001 > 0.0014External/SPEC/CFP2000/177_mesa/177_mesa-2.15%1.72141.68440.0017 > SingleSource/Benchmarks/CoyoteBench/fftbench-2.05%0.72800.71310.0049 > MultiSource/Benchmarks/TSVC/NodeSplitting-dbl/NodeSplitting-dbl-1.96% > 3.14943.08780.0034SingleSource/Benchmarks/Misc/oourafft-1.70%3.46253.4035 > 0.0009SingleSource/Benchmarks/Misc/flops-1.31%7.07756.98450.0014 > MultiSource/Applications/JM/lencod/lencod-1.12...

Most of libc++ doesn't have explicit template instantiations, which leads to a pretty significant build time and code size cost when using libc++, since a large number of common templates will be emitted by the compiler and coalesced by the linker. Notably, in include/__config, we have: #ifndef _LIBCPP_EXTERN_TEMPLATE #define _LIBCPP_EXTERN_TEMPLATE(...) #endif whereas before

...PCCG.test | 0.59 | 0.84 | 1.66 | 1.66 | |MultiSource/Benchmarks/McCat/05-eks/eks.test | 0.53 | 1.04 | 2.28 | 2.28 | |MultiSource/Applications/minisat/minisat.test | 0.90 | 0.76 | 1.49 | 1.81 | |SingleSource/Benchmarks/CoyoteBench/fftbench.test | 0.44 | 0.52 | 1.10 | 1.35 | |MultiSource/Benchmarks/Bullet/bullet.test | 0.36 | 0.47 | 0.33 | 2.34 | |MultiSource/Benchmarks/MiBench/consumer-typeset/consumer-typeset.| 0.26 | 0.43 | 0.79 | 0.79 | |MultiSource/Benchmarks/Olden/mst...

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

.../Benchmarks/Adobe-C++/simple_types_loop_invariant | * | * | SingleSource/Benchmarks/Adobe-C++/simple_types_constant_folding | * | * | SingleSource/Benchmarks/CoyoteBench/huffbench | * | * | SingleSource/Benchmarks/CoyoteBench/fftbench | * | * | SingleSource/Benchmarks/CoyoteBench/lpbench | * | * | SingleSource/Benchmarks/CoyoteBench/almabench | * | * | SingleSource/Benchmarks/McGill/misr...

...s/viterbi/viterbi -3.7% MultiSource/Benchmarks/MiBench/consumer-lame/consumer-lame -3.5% SingleSource/Benchmarks/Stanford/Puzzle -3.5% External/SPEC/CINT2006/401.bzip2/401.bzip2 -3.5% External/Povray/povray -3.4% MultiSource/Applications/oggenc/oggenc -3.4% SingleSource/Benchmarks/CoyoteBench/fftbench -3.4% SingleSource/Benchmarks/Shootout-C++/hash2 -3.4% MultiSource/Applications/ClamAV/clamscan +3.0% MultiSource/Applications/hexxagon/hexxagon +3.7% SingleSource/Benchmarks/Shootout/ary3 +3.8% MultiSource/Benchmarks/BitBench/uudecode/uudecode +4.0% MultiSource/Benchmarks/sim/sim +4.9% Sing...