Example program takes 2000 times as long to compile underC++ as C

[Mark Mitchell]

>>>>> "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