Nicholas Nethercote <[EMAIL PROTECTED]> writes: > 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 guess I think that is pretty well understood. We do in fact have a policy have primary/secondary/tertiary platforms, and we do informally prioritize languages. > - "New languages" -- why? Just because you can? In theory, adding a new > language can be free, but in practice it never is. Actually I think the various frontends are not too expensive. The main cost is testing time. We freely push frontend issues onto the frontend maintainers, except for C and C++. The current tree code issue is an exception, and it arises for historical reasons: the C and C++ frontends use the same tree structure as the middle-end. The C++ frontend used the structure first, and the middle-end borrowed it. > - "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. Fair enough. > - "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. It's hard to imagine anybody working on any other targets, but, OK. > - They're vague -- "improved runtime libraries"? "various other > infrastructure improvements"? These phrases are meaningless. Why not > just write "a really awesome compiler"? I think that would be a good goal. > - 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). I think you may misunderstand the mission statement. The mission statement is not a technical roadmap. It's a statement of general goals. If the community has a serious disagreement, the mission statement can sometimes help clarify matters. When there is no disagreement, the mission statement has no effect. > - They haven't been updated since 1999-04-22. Well, that's because the mission statement doesn't matter for day to day work. > 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) These all seem reasonable to me. The list is too long, though. > 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. The problem as I see it is that different gcc developers have different goals. And it is a natural tendency for developers to care more about their specific goals than any developer cares about the general goals. The effect is that specific goals get implemented at the expense of general goals. I don't have much of an opinion on whether we should change the mission statement. Changing it won't help with that problem. > > 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. Believe it or not, many developers look at the big picture all the time. Ian
