This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Example program takes 2000 times as long to compile underC++ as C
- To: zack at wolery dot cumb dot org
- Subject: Re: Example program takes 2000 times as long to compile underC++ as C
- From: Mark Mitchell <mark at codesourcery dot com>
- Date: Tue, 05 Sep 2000 21:35:07 -0700
- Cc: kelleycook at attglobal dot net, gcc-bugs at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org
- Organization: CodeSourcery, LLC
- References: <20000904202755.E295@wolery.cumb.org><20000905003815G.mitchell@codesourcery.com><20000905133547.I295@wolery.cumb.org>
>>>>> "Zack" == Zack Weinberg <zack@wolery.cumb.org> writes:
Zack> The patch also contains an additional tweak to
Zack> prune_unused_decls. If a BLOCK node ends up with no
Zack> variables after unused ones are discarded, it can be zapped
Zack> entirely. The SCOPE_STMT it's attached to then becomes
Zack> nullified. We can't get rid of the SCOPE_STMT itself,
Zack> because then expand_{start,end}_bindings won't get called,
Zack> but they do a fair bit less work if SCOPE_NULLIFIED_P is
Zack> true.
Good. I'd been meaning to do something like this for a while, but I'm
delighted you did.
Zack> Also it appears to be unnecessary for walk_tree to dink with
Zack> the current line number, but I may be missing something.
I agree; that's seems a little odd. That's from
2000-05-01 Jason Merrill <jason@casey.cygnus.com>
* tree.c (walk_tree): Set lineno.
Jason's message to gcc-patches said:
Fixes line numbers on error messages for g++.pt/crash6.C when compiled
with optimization.
Would you see if that's still true, before committing those bits?
Zack> This passes the C++ test suite with no regressions. I'm
Zack> running a bootstrap now.
The patch is fine, modulo the lineno thing above. As for the tail
recursion, I sort-of think we're likely to have to go to some kind of
queue to avoid the recursion at some point, but that makes debugging
much harder, so I'm trying to put it off until we really have to.
I have a feeling that the right fix for some of the present walk_tree
performance isues actually lie in clamping tree-based inlining; we
don't, so we sometimes inline too much stuff. We end up with huge
functions, which take a long time to compile and a lot of memory, and
we don't really end up with great code anyhow.
Thanks!
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com