Hi, a few days ago I noticed that the current mainline produces much worse code for one of my time-critical codes than it did a few weeks ago. After some testing I found out that the regression was introduced into CVS between the timestamps "-D 20050729 22:00:00 UT" and "-D 20050729 23:00:00 UT", so it appears that it was caused by Jan Hubicka's patch from http://gcc.gnu.org/ml/gcc-patches/2005-07/msg02021.html
I didn't have enough time so far to reduce the testcase much, but maybe it is already helpful to someone in its current state. The hot spot of the code is the strange loop in lines 134-139 of alm_map_tools_orig.cc. Yes, I know it looks really ugly and would welcome any hint how to write this more elegantly without losing efficiency :) Here are the results on a 3GHz Pentium 4 old compiler: ~/tmp/tmp2>g++ -O3 -march=pentium4 -mfpmath=sse testcase.cc ~/tmp/tmp2>time ./a.out 14.250u 0.020s 0:14.27 100.0% 0+0k 0+0io 205pf+0w new compiler: ~/tmp/tmp2>g++ -O3 -march=pentium4 -mfpmath=sse testcase.cc ~/tmp/tmp2>time ./a.out 22.430u 0.030s 0:22.46 100.0% 0+0k 0+0io 205pf+0w Both compilers have the same "g++ -v" output: ~/tmp/tmp2>g++ -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: /scratch/gcc/configure --quiet --prefix=/afs/mpa/data/martin/ugcc --enable-languages=c++ --enable-mapped-location --disable-checking Thread model: posix gcc version 4.1.0 20050729 (experimental) Should I open a PR? Cheers, Martin --
testcase.tar.gz
Description: application/tar-gz
