[llvm-testresults] cfarm-x86-64 x86_64 nightly tester results

This nightly tester is now using an llvm-g++ that produces the new ODR linkage
types. This means that many more functions are being considered by the
inter-procedural optimization passes (for example, "linkonce" functions defined
in a header). The result seems to be pretty huge swings (both good and bad) in
the C++ tests in the testsuite, see below. Note that this tester is often under
heavy load due to other users, so take timing results with a pinch of salt (a
pinch is about +-10% in my experience with this tester).

Ciao,

Duncan.

This nightly tester is now using an llvm-g++ that produces the new ODR linkage
types. This means that many more functions are being considered by the
inter-procedural optimization passes (for example, "linkonce" functions defined
in a header). The result seems to be pretty huge swings (both good and bad) in
the C++ tests in the testsuite, see below. Note that this tester is often under
heavy load due to other users, so take timing results with a pinch of salt (a
pinch is about +-10% in my experience with this tester).

Awesome 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/ffbench: -7.76% (3.61 => 3.89)
multisource/Applications/lambda-0.1.3/lambda: 18.24% (9.76 => 7.98)

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.

-Chris

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++ checking code is now being inlined (presumably
because it compiled to something smaller than before). Previously it was
not being inlined so was discarded, and the version from the system libstdc++
was used instead. My guess is that the system libstdc++ version is faster
because it doesn't do any checking. To test this theory I've told this
nightly tester to build llvm-gcc with checking disabled. If I'm correct
then stepanov_container/fftbench will speed up hugely in a few days time
when the tester starts using the new llvm-gcc.

Ciao,

Duncan.

Duncan Sands wrote:

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++ checking code is now being inlined (presumably
because it compiled to something smaller than before). Previously it was
not being inlined so was discarded, and the version from the system libstdc++
was used instead. My guess is that the system libstdc++ version is faster
because it doesn't do any checking. To test this theory I've told this
nightly tester to build llvm-gcc with checking disabled. If I'm correct
then stepanov_container/fftbench will speed up hugely in a few days time
when the tester starts using the new llvm-gcc.

If it helps, my nightly tester "desire" updates its version of llvm-gcc before every nightly test.

Nick

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++?

I don't know if it turns on checking in libstdc++, but I would be very surprised by that.

It seems that
a bunch of linkonce libstdc++ checking code is now being inlined (presumably
because it compiled to something smaller than before). Previously it was
not being inlined so was discarded, and the version from the system libstdc++
was used instead. My guess is that the system libstdc++ version is faster
because it doesn't do any checking. To test this theory I've told this
nightly tester to build llvm-gcc with checking disabled. If I'm correct
then stepanov_container/fftbench will speed up hugely in a few days time
when the tester starts using the new llvm-gcc.

Sounds great, thanks for hunting this down Duncan!

-Chris