Hello, there are many C++ compile-time regression in 3.4.0. I have tested it on MICO's ORB core sources and provide more detailed information to the gcc developers list: http://gcc.gnu.org/ml/gcc/2004-01/msg01458.html If you are curious, please download tarball of preprocessed sources here: http://www.mico.org/~karel/orb-ii-gcc340_040114.tar.bz2 Cheers, Karel
*** Bug 13776 has been marked as a duplicate of this bug. ***
*** Bug 13777 has been marked as a duplicate of this bug. ***
I believe this all are fixed by: 2004-01-26 Mark Mitchell <mark@codesourcery.com> * class.c (add_method): Just check processing_template_decl to determine whether or not we are within a template. * decl2.c (maybe_retrofit_in_chrg): Likewise. * init.c (decl_constant_value): Check the type of the declaration, not TREE_READONLY. * name-lookup.c (maybe_push_to_top_level): Rename to ... (push_to_top_level): ... this. * name-lookup.h (maybe_push_to_top_level): Do not declare it. * pt.c (push_template_decl_real): Reorder condition for speed. (convert_template_argument): Use dependency-checking functions in place of uses_template_parms. (lookup_template_class): Avoid calling uses_template_parms more than once. (uses_template_parms): Reimplement, using dependency-checking functions. (instantiate_class_template): Use push_to_top_level, not maybe_push_to_top_level. (type_unification_real): Simplify. (type_dependent_expression_p): Handle OFFSET_REFs and TEMPLATE_DECLs. (any_dependent_template_arguments_p): Handle multiple levels of template argument. * semantics.c (expand_or_defer_fn): Do not check uses_template_parms for template instantiations. * typeck.c (comptypes): Avoid calling cp_type_quals.
Subject: Re: Many C++ compile-time regression in 3.4.0 in comparison with 3.3.2 Have you tried it, or should I do it myself as a bug reporter? Thanks, Karel
I have not tried yet because I do not have a 3.3.2. As I should have said the patch which I pointed out is ment to speed up C++. Could you try as the reporter?
I have retested with the recent tree and results are provided here: http://gcc.gnu.org/ml/gcc/2004-01/msg02173.html The overall impression is very good, but still some interesting regressions are presented. Cheers, Karel
Okay so -O0 is no longer a regression which means that it is only the optimizers which. Thanks for testing.
Can you please do a -ftime-report? If the time is spent in combine, then this is a duplicate of PR13931.
Subject: Re: [3.4/3.5 Regression] Many C++ compile-time regression in 3.4.0 in comparison with 3.3.2 Sure! Here we go: (I've tested typecode.cc as it is the worst case) thinkpad:/mnt/karel/mico/orb$ time make typecode.pic.o c++ -I../include -time -ftime-report -O2 -Wall -DPIC -fPIC -c typecode.cc -o typecode.pic.o Execution times (seconds) garbage collection : 2.41 ( 7%) usr 0.00 ( 0%) sys 2.45 ( 6%) wall callgraph construction: 0.14 ( 0%) usr 0.00 ( 0%) sys 0.14 ( 0%) wall callgraph optimization: 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall cfg construction : 0.31 ( 1%) usr 0.02 ( 2%) sys 0.34 ( 1%) wall cfg cleanup : 0.49 ( 1%) usr 0.01 ( 1%) sys 0.52 ( 1%) wall trivially dead code : 0.52 ( 1%) usr 0.00 ( 0%) sys 0.52 ( 1%) wall life analysis : 0.98 ( 3%) usr 0.00 ( 0%) sys 1.00 ( 3%) wall life info update : 0.43 ( 1%) usr 0.00 ( 0%) sys 0.44 ( 1%) wall alias analysis : 0.80 ( 2%) usr 0.02 ( 2%) sys 0.82 ( 2%) wall register scan : 0.41 ( 1%) usr 0.00 ( 0%) sys 0.41 ( 1%) wall rebuild jump labels : 0.20 ( 1%) usr 0.00 ( 0%) sys 0.20 ( 1%) wall preprocessing : 0.38 ( 1%) usr 0.10 ( 8%) sys 0.51 ( 1%) wall parser : 4.38 (12%) usr 0.34 (26%) sys 4.88 (13%) wall name lookup : 2.32 ( 6%) usr 0.40 (30%) sys 2.88 ( 7%) wall expand : 8.22 (23%) usr 0.00 ( 0%) sys 8.42 (22%) wall varconst : 0.05 ( 0%) usr 0.02 ( 2%) sys 0.07 ( 0%) wall integration : 1.50 ( 4%) usr 0.02 ( 2%) sys 1.73 ( 4%) wall jump : 0.62 ( 2%) usr 0.11 ( 8%) sys 0.77 ( 2%) wall CSE : 2.60 ( 7%) usr 0.00 ( 0%) sys 2.68 ( 7%) wall global CSE : 2.46 ( 7%) usr 0.15 (11%) sys 2.67 ( 7%) wall loop analysis : 0.13 ( 0%) usr 0.00 ( 0%) sys 0.14 ( 0%) wall bypass jumps : 0.29 ( 1%) usr 0.03 ( 2%) sys 0.35 ( 1%) wall CSE 2 : 0.82 ( 2%) usr 0.00 ( 0%) sys 0.84 ( 2%) wall branch prediction : 0.40 ( 1%) usr 0.01 ( 1%) sys 0.41 ( 1%) wall flow analysis : 0.04 ( 0%) usr 0.00 ( 0%) sys 0.04 ( 0%) wall combiner : 0.48 ( 1%) usr 0.00 ( 0%) sys 0.50 ( 1%) wall if-conversion : 0.08 ( 0%) usr 0.00 ( 0%) sys 0.08 ( 0%) wall regmove : 0.19 ( 1%) usr 0.00 ( 0%) sys 0.19 ( 0%) wall local alloc : 0.42 ( 1%) usr 0.02 ( 2%) sys 0.44 ( 1%) wall global alloc : 1.12 ( 3%) usr 0.02 ( 2%) sys 1.19 ( 3%) wall reload CSE regs : 0.48 ( 1%) usr 0.00 ( 0%) sys 0.48 ( 1%) wall flow 2 : 0.10 ( 0%) usr 0.00 ( 0%) sys 0.14 ( 0%) wall if-conversion 2 : 0.08 ( 0%) usr 0.00 ( 0%) sys 0.09 ( 0%) wall peephole 2 : 0.12 ( 0%) usr 0.00 ( 0%) sys 0.15 ( 0%) wall rename registers : 0.13 ( 0%) usr 0.01 ( 1%) sys 0.15 ( 0%) wall scheduling 2 : 0.69 ( 2%) usr 0.01 ( 1%) sys 0.75 ( 2%) wall reorder blocks : 0.07 ( 0%) usr 0.00 ( 0%) sys 0.07 ( 0%) wall shorten branches : 0.10 ( 0%) usr 0.00 ( 0%) sys 0.10 ( 0%) wall final : 0.30 ( 1%) usr 0.00 ( 0%) sys 0.31 ( 1%) wall symout : 0.01 ( 0%) usr 0.01 ( 1%) sys 0.02 ( 0%) wall rest of compilation : 1.00 ( 3%) usr 0.01 ( 1%) sys 1.05 ( 3%) wall TOTAL : 36.31 1.32 38.99 # cc1plus 36.31 1.33 # as 0.29 0.02 real 0m40.410s user 0m37.000s sys 0m1.400s Cheers, Karel
Looking at the times: expand : 8.22 (23%) usr 0.00 ( 0%) sys 8.42 (22%) wall which means the middle-end just sucks.
I've just tried compiling the indicated typecode.cc.ii with -O2 -ftime-report on i686-pc-cygwin (3.5.0 20040131), and get very different numbers: garbage collection : 3.80 (10%) usr 0.00 ( 0%) sys 3.80 ( 9%) wall life analysis : 13.26 (34%) usr 0.03 ( 2%) sys 13.33 (33%) wall parser : 3.76 (10%) usr 0.37 (25%) sys 4.22 (10%) wall name lookup : 2.01 ( 5%) usr 0.70 (47%) sys 2.70 ( 7%) wall expand : 1.37 ( 4%) usr 0.01 ( 1%) sys 1.39 ( 3%) wall CSE : 1.70 ( 4%) usr 0.00 ( 0%) sys 1.70 ( 4%) wall global alloc : 3.03 ( 8%) usr 0.02 ( 1%) sys 3.06 ( 8%) wall TOTAL : 38.64 1.50 40.30 I'll try on x86/Linux, but if RTL expansion is a problem, its target dependent.
It looks like the original problem for which this PR was opened has been fixed. If there are compile-time regressions (perhaps target-specific), please create a new PR, with the source code and instructions for reproducing the bug.