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]

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

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

I'm not sure what checkin policy is appropriate for this branch.

I will do regular (hopefully weekly) merges from mainline to both
branches.  I will shortly add notes about both to the projects


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