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