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 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: Tue, 5 Sep 2000 22:46:16 -0700
- Cc: kelleycook at attglobal dot net, gcc-bugs at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org
- References: <20000904202755.E295@wolery.cumb.org> <20000905003815G.mitchell@codesourcery.com> <20000905133547.I295@wolery.cumb.org> <20000905213507E.mitchell@codesourcery.com>
On Tue, Sep 05, 2000 at 09:35:07PM -0700, Mark Mitchell wrote:
> >>>>> "Zack" == Zack Weinberg <zack@wolery.cumb.org> writes:
>
> 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?
Unfortunately, it is still true. The test suite doesn't try that one
with optimization, so I missed it.
I'll apply the patch with the line number dinking put back into
walk_tree, but not walk_stmt_tree (since I know that its users can't
cause problems).
> 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.
My point was more that this is an obvious case, and the tail recursion
optimizer isn't doing its job. I could have done it by hand:
return walk_tree (&TREE_OPERAND (*tp), ...);
becomes
tp = &TREE_OPERAND (*tp);
goto top_of_function;
but I'd rather see sibcall fixed. (I don't have time to do it myself.
Hypothesis: maybe it thinks the recursive call uses the address of an
object in the current function's stack frame?)
I need to finish cleaning up the integrated preprocessor patch, then
I'll try us out on Apple's monster test case again. I think that hits
an entirely different set of bottlenecks :(
zw