This is the mail archive of the 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]

Discussion about a new development plan? (was: Re: [tree-ssa] ASToptimizer in C++?)


Many Great New Improvements for GCC have been discussed lately on this
mailing list. Maybe it's time to devise a sane development plan, to see
what is feasable for what release, and in what time frame.

I know this isn't quite how Free Software is usually developed. But
since GCC is an essential tool for almost everybody in the Open Source
world, I think people will appreciate if they know what to expect
(without making any promises, of course ;-).

(most of you already know this, so skip it or correct me)

Right now there are at least four projects ongoing that involve lots of
infrastructure changes or major rewrites:
1) The new (tree-based?) optimizer framework that people are working
   on in the tree-ssa branch.
2) The other "major rework" project on the cfg-branch, where Jan Hubicka
   and others were working on loop optimizers and midRTL.
3) The new, hand-crafted C++ parser in the cp-parser branch.
4) PCH work in the pch-branch. One guy, many improvements :-)

(BTW It would be nice to see more regular status updates for each
branch, hint hint...)

One would guess this would require all resources available for GCC
development (think `people' and `time' here, not money). But this week,
two new branches were announced. That means that GCC hackers now have 6
branches plus the mainline to deal with. Isn't that going to be a
potential branch maintainer nightmare?

To make things worse, many invasive changes have been discussed in this
mailing list lately, most notably the idea of doing at least some of the
optimizers in C++, which will probably require new bootstrap
infrastructure. That's the kind of thing for a new major release, I
would think...
Add to that the C++ ABI problems and hopefully a test suite to solve
those, the plan to move the C front end to its own directory, the
conversion from K&R to ISO/ANSI C, etc...

In short: GCC is now more than ever a moving target :-(

That's bad for disto builders, it's bad for the gcc users community, and
it's bad for GCC developers as well! For example, the GNU Pascal
compiler still would not even compile as part of GCC 3.0 last time I
looked (GC work isn't done yet).

I suppose most people would agree that it'd be nice to have a stable GCC
release branch for a while, maybe with some bug fixes and compilation
time improvements, but not too many changes.


So maybe we could discuss a new development plan. The old one doesn't
say anything about what's beyond GCC 3.3, so this seems like the right
Here are my ideas:

I tried to devide the ongoing projects in three categories:
a) suitable for relatively quick merge:
	- PCH work. Most of the infrastructure is already there,
	  and (correct me if I'm wrong) the remaining work should
	  not affect anything in the middle-end or back-end.
	- Most of what's on the cfg-branch now.
	- Anything gcc-3_4-basic-improvements-branch, by definition.

b) long-term, invasive reworks and massive infrastructure changes
	- faster-compiler stuff. It would seem this could easily
	  cause conflicts with the tree-ssa stuff, so maybe it's better
	  to put them together on a single branch.
	- tree-ssa-branch. This is starting to look more and more
	  like a complete new middle-end.
	- More builtin folding (and/or expand BUILTIN_FRONTEND to
	  trees instead of RTL?)
	- All ISO C for source code not required for bootstraping.
	- New C++ parser, and converting other front ends to
	  function-at-a-time mode
	- Bug-free (*cough*) C++ ABI, with testing framework

c) very long term ideas
	- Cross-file interprocedural optimizations and alike. Most
	of this obviously is related to items under (b), but it seems
	far more ambitious.
	- auto-vectorizing pass (as part of middle-end optimizers)

With these categories in mind, you could say, OK, stuff under (a) is
what we want in the 3.x release series. Stuff under (b) is for GCC 4.0,
and (c) is for 4.x (x>0) and beyond.

This means that disto builders/users can rely on GCC producing binary
compatible code for C++ for all GCC 3.x compilers. It also means that no
GCC 3.x will be much faster than what we have now, but I'm not sure how
big an issue this really is, especially once PCH is in.

Once it has been decided how the new optimizers should be implemented
(language, IR, etc), and after 3.3 has been branched, we could branch a
The mainline would be the base code for 3.4, 3.5, 3.6, and maybe 3.7,
depending on how well things would work out on the middle-end-branch.
Assuming one minor release every six months, GCC 3.6 would be released
in April 2004.

Anything that's on the tree-ssa and faster-compiler branches by then
would be merged onto this new middle-end-branch. Work on this branch
would include:
1) Move the C front end to its own directory and move stuff from
c-common.* to, say, tree-ir.*. (Maybe this should be done on the
"stable" branch as well to avoid huge merge conflicts???)
2) Figure out how to bootstrap with part of the sources written in C++
3a) Implement the new middle-end, using C++ and ISO C (with backports to
the mainline and release branch to avoid merge conflicts), and
3b) Convert the existing front ends to function-at-a-time mode to allow
them to actually use this infrastructure.
4) Include new front ends such as g95 and GNU Pascal??

Actually (3b) may be relevant only to GNU Pascal and GNAT, unless
somebody with serious brain damage stands up and volunteers to rewrite
g77. It may be better to concentrate in g95 instead, it already depends
on much of what is in the tree-ssa branch today, and it actually
produces code (well, for some programs at least).

As is being actively discussed right now, some optimizers will probably
be written in C++, so a stable g++ would be crucial for the work on the
middle-end-branch. Therefore, any major C++ work should be done on a
separate branch. The new C++ parser and all ABI fixes would go on the
cp-parser branch (renamed future-cxx branch by then?), and fixes would
be merged to the middle-end branch only after thourough testing.

Assuming the C++ parser can be finished within one and a half year
(CodeSourcery is working on it again, right?) and the work on the
middle-end will progress at the same speed it has been on in the last
half year, a GCC 4.0 alpha could be ready at about the same time you'd
release 3.6.

Unfortunately nobody can tell how realistic this timeframe is. I suppose
I'm being a bit optimistic... I would certainly like to hear your
opinions ;-)

Sorry for the long mail. I just hope this gets a discussion going...


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