This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]