Bug 13775 - [3.4/4.0 Regression] Many C++ compile-time regression in 3.4.0 in comparison with 3.3.2
Summary: [3.4/4.0 Regression] Many C++ compile-time regression in 3.4.0 in comparison ...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 3.4.0
: P2 normal
Target Milestone: 3.4.0
Assignee: Not yet assigned to anyone
URL:
Keywords: compile-time-hog
: 13777 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-01-20 18:34 UTC by Karel Gardas
Modified: 2004-09-13 14:15 UTC (History)
4 users (show)

See Also:
Host: i686-pc-linux-gnu
Target: i686-pc-linux-gnu
Build: i686-pc-linux-gnu
Known to work:
Known to fail:
Last reconfirmed: 2004-01-29 15:17:54


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Karel Gardas 2004-01-20 18:34:49 UTC
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
Comment 1 Wolfgang Bangerth 2004-01-20 18:52:52 UTC
*** Bug 13776 has been marked as a duplicate of this bug. ***
Comment 2 Wolfgang Bangerth 2004-01-20 18:53:24 UTC
*** Bug 13777 has been marked as a duplicate of this bug. ***
Comment 3 Andrew Pinski 2004-01-28 17:58:21 UTC
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.
Comment 4 Karel Gardas 2004-01-28 18:01:33 UTC
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


Comment 5 Andrew Pinski 2004-01-28 18:04:21 UTC
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?
Comment 6 Karel Gardas 2004-01-29 11:29:53 UTC
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
Comment 7 Andrew Pinski 2004-01-29 15:17:52 UTC
Okay so -O0 is no longer a regression which means that it is only the optimizers which.  Thanks 
for testing.
Comment 8 Paolo Bonzini 2004-01-30 19:25:24 UTC
Can you please do a -ftime-report?  If the time is spent in combine, then this 
is a duplicate of PR13931.
Comment 9 Karel Gardas 2004-01-30 21:14:57 UTC
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


Comment 10 Andrew Pinski 2004-02-04 16:38:24 UTC
Looking at the times:
 expand                :   8.22 (23%) usr   0.00 ( 0%) sys   8.42 (22%) wall
which means the middle-end just sucks.
Comment 11 roger 2004-02-05 04:56:16 UTC
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.
Comment 12 Mark Mitchell 2004-03-13 16:31:35 UTC
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.