------- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-18 18:23 ------- Here are the current timings for the mainline and 3.3: mainline: [zhivago:~/src/localgccPRs] pinskia% time ~/local3/bin/gcc -S pr15524.c -O1 27.680u 1.240s 0:32.98 87.6% 0+0k 0+6io 0pf+0w
3.3: [zhivago:~/src/localgccPRs] pinskia% time gcc -S pr15524.c -O1 14.260u 0.560s 0:16.30 90.9% 0+0k 0+4io 0pf+0w At -O0: mainline: [zhivago:~/src/localgccPRs] pinskia% time ~/local3/bin/gcc -S pr15524.c 2.790u 0.350s 0:03.52 89.2% 0+0k 0+3io 0pf+0w 3.3: [zhivago:~/src/localgccPRs] pinskia% time gcc -S pr15524.c 1.930u 0.280s 0:02.28 96.9% 0+0k 1+3io 0pf+0w Note that is this on powerpc-darwin and with Apple's 3.3 (build 1650 or so). So we are still twice as slow as 3.3 but faster than before. Using -ftime-report I get: dominator optimization: 11.69 (42%) usr 0.13 ( 4%) sys 12.28 (38%) wall rename registers : 3.32 (12%) usr 0.12 ( 4%) sys 3.62 (11%) wall So only DOM needs to be sped up. For DOM the problem comes from thread_across_edge when we go and update the profile of the BB. For renane registers, most of a profile of compiling this source comes from regrename.c the loop which is around line 1761. -- What |Removed |Added ---------------------------------------------------------------------------- Severity|critical |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15524