We're out of tree codes; now what?

[Nicholas Nethercote]

On Mon, 19 Mar 2007, Doug Gregor wrote:

> But what is the solution? We can complain about performance all we
> want (and we all love to do this), but without a plan to fix it we're
> just wasting effort. Shall we reject every patch that causes a slow
> down? Hold up releases if they are slower than their predecessors?
> Stop work on extensions, optimizations, and bug fixes until we get our
> compile-time performance back to some predetermined level?
>
> We have hit a hard limit in the design of GCC. We need to either use
> more memory, use more compilation time, re-architect non-trivial
> portions of GCC, remove functionality, or come up with something very,
> very clever. Pick one, but if the pick the last one, you have to
> specify what "something very, very clever" is, because we seem to be
> running short on ideas.

GCC is a very ambitious compiler:

- it supports a lot of platforms
- it supports a lot of languages

However, most users do not use most of those combinations.  The problem is 
that supporting all these combinations hurts the specific combinations.

For example, I almost always compile C, and usually on x86 or AMD64.  So I 
don't care if the C++ compiler has improved, or a new language front-end is 
added, or whatever.  (Other users will have different priorities.)

As for what is best to do, I don't know.  But I do know that complexity is 
bad, and that GCC is very complex.  You are absolutely right about there 
being hard limits.  There are trade-offs required.  Whether the current and 
ongoing trade-offs are the right ones is an open question.

Nick