GCC 4.10 Performance: Not Much To See Yet
Phoronix: GCC 4.10 Performance: Not Much To See Yet
GCC 4.9 was released at the end of April so this weekend I ran some fresh compiler benchmarks of the latest GCC 4.10 compiler snapshot to see if there's been any performance improvements thus far in the 4.10 development cycle, although GCC 4.10 will not be released until 2015...
Changes in GCC 4.10
GCC 4.9 forked in mid April, so 2 months of stage 1 is still bit early for performance tuning.
So far stage1 was more about cleanups and memory layout improvements. New wide-int replaced older wide in implementations in the compiler (that are frequent because the compiler must be able to cross from 32bit host to 64bit taret), Richard Standiford improved compile time performance of RTL backend (dataflow and instruction pattern matching), Symbol table is now associated with declarations without external hash resulting in faster lookups and better memory layout. This also allow to store more information about symbols in there improving the IL maintability/memory use and LTO streaming. Work on cleaning up updating APIs to C++ style continues.
There are optimization improvements, too - register allocator is slowly getting inter-procedural, interprocedural constant propagation gets stronger on propagation aggregate values (this matters for Fortran and C++), write only static variable removal, better alias analysis in LTO, propagation of symbols into COMDAT sections, optimization of references in virtual tables for faster dynamic linking etc. Also there was number of improvements in x86/rs6000/arm backends.
Some interesting features are coming - Martin Liska's identical code folding, Google's autoFDO, more devirtualization improvements etc.
Short discussion on 4.10 plans was here https://gcc.gnu.org/ml/gcc/2014-05/msg00241.html
[unrelated gcc rant]
So in the recent months I've found two compiler bugs. Both are such that I failed two create a minimal testcase, and so did not file them, as "yo, provable compiler bug in this huge codebase" reports aren't really welcome on gcc bugzilla :P Listing both here for google's sake.
GCC 4.7.2 fails when building busybox dc on x86. A double is supposed to be passed on the stack, but is somehow read from a completely magic location, producing nonsense. Thread on bb ml. Took days to find.
GCC 4.8.3 fails in webkit on x64, a nice 5.6M codebase. A C++ object allocated on the stack is randomly uninitialized (which is not possible from the code), which passed to a hash function created an obviously random value. This lead to a wrong value being removed from the hash table and a crash. I worked around this by simply allocating the object on the heap.
Took close to a week to find. One tell-tale sign of a compiler bug like this is when adding a printf changes the behavior. This happened in both cases: printing the double caused correct code to be produced, printing the stack value also caused correct code. Be nice if you could trust your compiler
Without a testcase it is hard to tell, but this smells like you're invoking undefined behavior in your code.
Originally Posted by curaga
The compiler is allowed to do anything in this case. Please build with gcc 4.9 and -fsanitize=undefined and
look for any issues it reports during runtime.
Neither was undefined behavior. I welcome you to check the bb dc source, it's a short file.
Building gcc 4.9 git and either project would take an hour. I incidentally have better things to do with that hour
Webkit builds just fine with any version of gcc 4.8, I do so regularly. There was a bug in ANGLE that causes it to crash with gcc 4.9, the fix in being merged to ANGLE.
Originally Posted by curaga