This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: Example program takes 2000 times as long to compile under C++ as C
- To: Mark Mitchell <mark at codesourcery dot com>
- Subject: Re: Example program takes 2000 times as long to compile under C++ as C
- From: Zack Weinberg <zack at wolery dot cumb dot org>
- Date: Mon, 4 Sep 2000 20:27:55 -0700
- Cc: kelleycook at attglobal dot net, gcc-bugs at gcc dot gnu dot org
- References: <20000830162923.H13918@wolery.cumb.org> <20000831105514D.mitchell@codesourcery.com> <20000904120724.D295@wolery.cumb.org> <20000904152646A.mitchell@codesourcery.com>
On Mon, Sep 04, 2000 at 03:26:46PM -0700, Mark Mitchell wrote:
>
> Well, it depends what you mean. SAVE_EXPRs are supposed to appear in
> tree structure several times over, and that's part of why I think they
> are evil. I'm not quite sure why we'd get there *that* many times,
> and I think we should understand that better.
>
> In this particular case, it looks like we are creating a lot more
> SAVE_EXPRs than we need to; there's nothing about that function that
> should require any SAVE_EXPRs, really. (There's nothing about what
> you showed that has any side-effects.) So, I bet that in this case,
> there is an easy fix. Send me the complete source code for a pared
> down test-case; I promise to look at it today.
Sorry, I was out all day. I've been using Kelley's original test
case; below is a preprocessed version. You don't need any special
arguments. If you want a smaller tree to look at, just cut out
(inN ? 0xf00 : 0) |
lines.
N.B. If I use a hash table to remember all the trees visited by
calls_setjmp_p_r and simplify_aggr_init_exprs_r, and I clear
walk_subtrees and return on subsequent visits to each tree, processing
time for this test case drops from 90s to 0.04s - both figures with
stage1 cc1plus, so no optimization. I also see moderate improvement
in time to run the C++ test suite. But g++.other/defarg[45].C get
bizarre aborts in function.c. I don't know why yet. The code in
function.c that triggers has to do with nested functions and there
aren't any in those test cases.
zw
bool in0 ;
bool in1 ;
bool in2 ;
bool in3 ;
bool in4 ;
bool in5 ;
bool in6 ;
bool in7 ;
bool in8 ;
bool in9 ;
bool in10;
bool in11;
bool in12;
bool in13;
bool in14;
bool in15;
unsigned int output;
void mux(void)
{
output =
(in0 ? 0x0001 : 0) |
(in1 ? 0x0002 : 0) |
(in2 ? 0x0004 : 0) |
(in3 ? 0x0008 : 0) |
(in4 ? 0x0010 : 0) |
(in5 ? 0x0020 : 0) |
(in6 ? 0x0040 : 0) |
(in7 ? 0x0080 : 0) |
(in8 ? 0x0100 : 0) |
(in9 ? 0x0200 : 0) |
(in10 ? 0x0400 : 0) |
(in11 ? 0x0800 : 0) |
(in12 ? 0x1000 : 0) |
(in13 ? 0x2000 : 0) |
(in14 ? 0x4000 : 0) |
(in15 ? 0x8000 : 0) ;
}