This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug optimization/2692] excessive compile time with optimization
- From: "steven at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 25 Jul 2003 10:49:16 -0000
- Subject: [Bug optimization/2692] excessive compile time with optimization
- References: <20010429210601.2692.snyder@fnal.gov>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2692
------- Additional Comments From steven at gcc dot gnu dot org 2003-07-25 10:49 -------
This is still slow, but not as bad as it used to be. Here are time reports from
what I get on an Athlon XP2000 with 256MB RAM, for "g++-3.4 (GCC) 3.4 20030718
(experimental)":
$ g++-3.4 -c -ftime-report 2692.cc
Execution times (seconds)
cfg construction : 0.02 ( 2%) usr 0.00 ( 0%) sys 0.02 ( 2%) wall
trivially dead code : 0.01 ( 1%) usr 0.00 ( 0%) sys 0.01 ( 1%) wall
life analysis : 0.10 ( 9%) usr 0.00 ( 0%) sys 0.10 ( 8%) wall
life info update : 0.03 ( 3%) usr 0.00 ( 0%) sys 0.03 ( 3%) wall
register scan : 0.01 ( 1%) usr 0.00 ( 0%) sys 0.01 ( 1%) wall
parser : 0.12 (11%) usr 0.01 (17%) sys 0.14 (12%) wall
name lookup : 0.01 ( 1%) usr 0.02 (33%) sys 0.04 ( 3%) wall
expand : 0.09 ( 8%) usr 0.01 (17%) sys 0.10 ( 8%) wall
integration : 0.03 ( 3%) usr 0.00 ( 0%) sys 0.03 ( 3%) wall
flow analysis : 0.02 ( 2%) usr 0.00 ( 0%) sys 0.02 ( 2%) wall
local alloc : 0.11 (10%) usr 0.00 ( 0%) sys 0.11 ( 9%) wall
global alloc : 0.34 (31%) usr 0.00 ( 0%) sys 0.34 (29%) wall
flow 2 : 0.03 ( 3%) usr 0.00 ( 0%) sys 0.03 ( 3%) wall
shorten branches : 0.04 ( 4%) usr 0.00 ( 0%) sys 0.04 ( 3%) wall
reg stack : 0.01 ( 1%) usr 0.00 ( 0%) sys 0.01 ( 1%) wall
final : 0.06 ( 5%) usr 0.01 (17%) sys 0.07 ( 6%) wall
rest of compilation : 0.08 ( 7%) usr 0.01 (17%) sys 0.09 ( 8%) wall
TOTAL : 1.11 0.06 1.19
$ g++-3.4 -c -O -ftime-report 2692.cc
Execution times (seconds)
garbage collection : 0.17 ( 0%) usr 0.01 ( 3%) sys 0.68 ( 0%) wall
cfg construction : 0.11 ( 0%) usr 0.00 ( 0%) sys 0.11 ( 0%) wall
cfg cleanup : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.07 ( 0%) wall
trivially dead code : 0.13 ( 0%) usr 0.01 ( 3%) sys 0.14 ( 0%) wall
life analysis : 99.39 (67%) usr 0.06 (17%) sys 105.98 (66%) wall
life info update : 0.04 ( 0%) usr 0.00 ( 0%) sys 0.04 ( 0%) wall
alias analysis : 0.21 ( 0%) usr 0.01 ( 3%) sys 0.24 ( 0%) wall
register scan : 0.08 ( 0%) usr 0.01 ( 3%) sys 0.09 ( 0%) wall
rebuild jump labels : 0.05 ( 0%) usr 0.00 ( 0%) sys 0.05 ( 0%) wall
preprocessing : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall
parser : 0.12 ( 0%) usr 0.00 ( 0%) sys 0.13 ( 0%) wall
name lookup : 0.00 ( 0%) usr 0.03 ( 8%) sys 0.03 ( 0%) wall
expand : 0.52 ( 0%) usr 0.05 (14%) sys 0.60 ( 0%) wall
varconst : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall
integration : 0.47 ( 0%) usr 0.01 ( 3%) sys 0.48 ( 0%) wall
jump : 0.06 ( 0%) usr 0.00 ( 0%) sys 0.06 ( 0%) wall
CSE : 2.65 ( 2%) usr 0.03 ( 8%) sys 3.05 ( 2%) wall
loop analysis : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall
branch prediction : 0.06 ( 0%) usr 0.00 ( 0%) sys 0.06 ( 0%) wall
flow analysis : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall
combiner : 6.36 ( 4%) usr 0.00 ( 0%) sys 6.79 ( 4%) wall
if-conversion : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall
local alloc : 0.33 ( 0%) usr 0.01 ( 3%) sys 0.48 ( 0%) wall
global alloc : 34.50 (23%) usr 0.11 (31%) sys 39.30 (24%) wall
reload CSE regs : 1.60 ( 1%) usr 0.00 ( 0%) sys 1.81 ( 1%) wall
flow 2 : 0.06 ( 0%) usr 0.00 ( 0%) sys 0.07 ( 0%) wall
rename registers : 0.14 ( 0%) usr 0.00 ( 0%) sys 0.15 ( 0%) wall
shorten branches : 0.06 ( 0%) usr 0.00 ( 0%) sys 0.08 ( 0%) wall
reg stack : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.04 ( 0%) wall
final : 0.09 ( 0%) usr 0.01 ( 3%) sys 0.13 ( 0%) wall
rest of compilation : 0.31 ( 0%) usr 0.00 ( 0%) sys 0.32 ( 0%) wall
TOTAL : 147.62 0.36 161.10
So the expand hog is gone :-)
It's not a surprise that, for the test case for this PR, global alloc and life
analysis take so much time. It would obviously be nice to have it faster, but
it is not the awful compile time hog anymore.
Richard, I have not reconfirmed this PR because I am not sure what's reasonable
here. Do you think this report can be closed, or do you think these timings
still are unacceptable?
Gr.