Results 1 to 7 of 7

Thread: GCC 4.10 Performance: Not Much To See Yet

  1. #1
    Join Date
    Jan 2007
    Posts
    15,703

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

    http://www.phoronix.com/vr.php?view=MTcyMDY

  2. #2
    Join Date
    Aug 2012
    Posts
    46

    Default 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

  3. #3
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,341

    Default

    [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

  4. #4
    Join Date
    Jun 2014
    Posts
    1

    Default

    Quote Originally Posted by curaga View Post
    [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.
    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.

  5. #5
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,341

    Default

    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

  6. #6
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,341

  7. #7
    Join Date
    Nov 2012
    Posts
    213

    Default

    Quote Originally Posted by curaga View Post
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •