This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
REPOST: Announcing the basic-improvements and faster-compiler branches
- From: Zack Weinberg <zack at codesourcery dot com>
- To: gcc at gcc dot gnu dot org
- Date: Mon, 26 Aug 2002 00:40:48 -0700
- Subject: REPOST: Announcing the basic-improvements and faster-compiler branches
I'm reposting this since it got no reaction the first time round,
which was toward the end of the week, so perhaps it dropped off
people's radar.
-----
We have a certain amount of momentum on basic improvements and major
performance work right now; it would be a shame to lose that due to
the code freeze. I've therefore created two branches in the CVS
repository:
gcc-3_4-basic-improvements-branch: This branch is for basic,
straightforward improvements, which will be easy to merge back into
the mainline at the beginning of development stage 1 for gcc 3.4. I
do not intend this branch to continue past that point, hence the name.
Examples of work appropriate for this branch:
- Continued conversion of target macros to target hooks.
- Other cleanup work on the back-end interface.
- Continued conversion of front-end interfaces to language hooks.
- Other cleanup work on the front-end interface.
- Continued elimination of CPP_PREDEFINES.
- Continued removal of target dependencies from cpplib.
Checkins to this branch require approval as if they were being
considered for checkin to the mainline during Stage 2 development.
faster-compiler-branch: This one is for major invasive work to make
the compiler go faster. Anything goes as long as it comes with a
measurable performance improvement, but would not be appropriate to
include in the mainline. However, PCH is specifically excluded from
this branch, as we already have a branch for that. This branch is
likely to be longer lived, although I hope that most or all of the
changes will be suitable for inclusion in 3.4.
Examples of work appropriate for this branch:
- Reducing the size of data structures.
- Eliminating pointers between tree and RTL.
- Exploring different memory allocation algorithms.
- Exploring a "compact" RTL representation.
- Squelching quadratic or worse algorithmic bottlenecks, such as
fixup_var_refs.
I'm not sure what checkin policy is appropriate for this branch.
Suggestions?
I will do regular (hopefully weekly) merges from mainline to both
branches. I will shortly add notes about both to the projects
webpage.
zw