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]

Announcing the basic-improvements and faster-compiler branches


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


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