I was asked yesterday whether making performance improvements during Stage 3 is appropriate, so I'll attempt to clarify this point.
Such patches are definitely appropriate, provided that they're targeted at regressions/bugs, and not attempts to sneak in new features. For example, if the scheduler generates slow code because it's not computing dependencies correctly, then fixing that is entirely reasonable in Stage 3. Rewriting the scheduler from scratch would not be. If the loop optimizer is too conservative about doing unrolling, then making it more agressive is a bug-fix; adding an entirely new loop optimization probably is not. This isn't a bright-line thing, but submitters and reviewers can use their judgement to determine what's a bug-fix and what's not. Certainly, one of the primary goals for GCC is to generate fast code, and there's been a lot of work in that direction. If we're actually slower than previous releases (as some SPEC testers on some platforms suggest), then that's a regression, just like a new ICE, and we should try to fix it. It is true that as we get very close to a release, we might decide that it's worth fixing a wrong-code regression, but not worth risking trouble to improve scheduling, but we're not at that point yet. If you have a particular patch in hand, and you're not comfortable deciding whether it's reasonable to include it, feel free to ask me. Thanks, -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304