GCC priorities [Was Re: We're out of tree codes; now what?]

Nicholas Nethercote njn@csse.unimelb.edu.au
Tue Mar 20 21:38:00 GMT 2007


On Tue, 20 Mar 2007, Nicholas Nethercote wrote:

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

Nobody responded to this particular point, which surprised me.  I looked up 
the GCC mission statement (http://gcc.gnu.org/gccmission.html).  It has the 
following "Design and Development Goals"

     * New languages
     * New optimizations
     * New targets
     * Improved runtime libraries
     * Faster debug cycle
     * Various other infrastructure improvements

I think they're terrible:

- "New languages" -- why?  Just because you can?  In theory, adding a new
   language can be free, but in practice it never is.

- "New optimizations?"  I assume this means "optimization passes".
   Users don't care about optimization passes.  Users care
   about performance.  Optimizations happen to be the main way to achieve
   that, but substituting the mechanism for the end goal in a mission
   statement sends the wrong message.

- "New targets" -- this one is better, but some qualification would help.
   I understand that the goal is for GCC to be the universally available
   compiler, but it could be clarified that it's targets that are desired by
   users.

- They're vague -- "improved runtime libraries"?  "various other
   infrastructure improvements"?  These phrases are meaningless.  Why not
   just write "a really awesome compiler"?

- There's no notion that you can't have everything.  For something to be a
   high priority, you have to make something else a lower priority.  This
   list is just "faster! better! more!"  In particular, to return to the
   original point of this thread, the "faster debug cycle" has been suffering
   horribly (due to compile-time performance regressions).

- They haven't been updated since 1999-04-22.

Here are some suggestions for more suitable priorities.  They're all 
characteristics, rather than features.  They're far from perfect, but I 
think they're better than the goals above.  I haven't put them in any 
particular order.

- Correctness w.r.t. language definitions (ie. accept correct code, reject
   incorrect code)
- Correctness of the compiler (ie. no compiler crashes)
- Correctness of generated code (ie. compiled code should do the right
   thing)
- Performance of the compiler (time and memory)
- Performance of generated code (time and memory)
- Performance of building the compiler (time and memory)
- Support of existing language extensions
- Addition of new language extensions
- Support of existing languages: C, C++, Objective C, Fortran, Ada, Java
   (and any others I've missed)
- Support of new languages
- Support of existing platforms (a.k.a. portability)
- Support of new platforms (a.k.a. portability)
- Design and code complexity
- Maintainability
- Debugging support (eg. generating correct debugging info)
- Profiling support
- Quality of error messages (eg. uninitialized variables)
- Support for other extensions (eg. mudflap)

You can split these up or qualify them more, eg. for "performance of the 
compiler" you might distinguish between -O0 and -O2.

The key idea is that you can't have all of these.  For example, supporting 
many languages and platforms increases complexity, adds more code (which 
slows down build times), and can hurt performance (as the tree codes example 
has shown).  It also takes resources that then are not used for improving 
other aspects.  Another example: there was a suggested SoC project yesterday 
for an incremental C++ parser.  That could speed up compile-time performance 
in some cases, but at the cost of increased design and code complexity.

This idea is simple, and I'm sure many of you understand it individually. 
But it appears to me, as an observer of GCC development, that GCC developers 
as a group don't understand this.


On Mon, 19 Mar 2007, Doug Gregor wrote:

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

Doug was talking about the tree code issue, but this paragraph sums up the 
whole situation perfectly.  Sometimes it's a good idea to stand back and 
look at the bigger picture, rather than just running on the "gotta fix 
another bug, gotta add another feature" treadmill.

Nick



More information about the Gcc mailing list