Performance patches during Stage 3

[Mark Mitchell <mark at codesourcery dot com>]

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
mark@codesourcery.com
(916) 791-8304