A code quality regression was introduced into CVS between the timestamps "-D 20050729 22:00:00 UT" and "-D 20050729 23:00:00 UT". It appears that it iss caused by Jan Hubicka's patch from http://gcc.gnu.org/ml/gcc-patches/2005-07/msg02021.html If the attached testcase is compiled with the newer compiler, the runtime of the generated executable is more than 50 per cent higher: 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) The hot spot of the code is the strange "loop" in lines 134-139 of alm_map_tools_orig.cc.
Created attachment 9494 [details] A testcase for the problem
Ouch. This badly needs reducing...
I think this is related to PR 23302 and PR 23303 since those look like they were caused by the same patch.
(In reply to comment #2) > Ouch. This badly needs reducing... Absolutely. But since Andrew pointed out that it is probably related to PR 23302 and PR 23303 (which have nice testcases), I suggest I wait until these are fixed. If, after that, the performance regression persists, I'll try to reduce the testcase. Is that OK?
Leaving as P2.
I don't have P4 to test handy. Can you re-test whether fixing 23302 (23303 is invalid) make any difference? I doubt these two make actual runtime changes - the sequence would translate to same uops for P4 and should execute in about the same time.
The regression is unfortunately still there :( Reducing the testcase is really hard, and I have some indications that the problem vanishes if there is less work to do in the critical loop. If you have any suggestion how to proceed, they would be greatly appreciated ...
I re-tested today with versions 3.3.2, 4.0-branch, 4.1-branch, trunk and gomp-branch, and could not reproduce the regression any more. So I think this report can be closed. Thanks to the unknown patcher! ;)
Fixed so closing as such.