This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: DFA scheduler merge - approval issues?
- From: Geoff Keating <geoffk at geoffk dot org>
- To: Daniel Berlin <dberlin at dberlin dot org>
- To: tm <tm at mail dot kloo dot net>
- Cc: gcc at gcc dot gnu dot org, <vmakarov at cygnus dot com>
- Date: 10 Apr 2002 11:39:39 -0700
- Subject: Re: DFA scheduler merge - approval issues?
- References: <Pine.LNX.4.44.0204101400270.4068-100000@dberlin.org>
Daniel Berlin <dberlin@dberlin.org> writes:
> On Wed, 10 Apr 2002, tm wrote:
>
> >
> > I'm wondering what issues are preventing the DFA scheduler from being
> > approved for inclusion into the mainline source?
> I'm also curious.
> I know Vlad sent a message asking if he could merge it, after we
> branched for 3.1.
> Nobody responded.
Sigh, a dropped ball.
I've been thinking about how to do such things from the viewpoint of
merging the PCH branch. Here's a checklist of things to do before
merging the DFA scheduler:
1. Post the patch, as it will be applied to the mainline, to
gcc-patches; if it's large, post a pointer on gcc-patches and put
it on a web site (say people.redhat.com). The patch should be
made by merging mainline onto the branch, and then doing a diff
between the mainline and the branch. I will review the patch.
2. State, in the message, which platforms the patch was tested. There
has to be at least three. Hopefully every platform for which the
new scheduler will be used will be tested.
3. Since this is about performance, some performance statistics should
be provided. I believe Vlad has some SPEC results, which would be
good to provide in the message; in particular, it's important that
the patch doesn't cause performance to significantly decrease on
any platform (I'm thinking of powerpc), even if it only provides a
benefit for some platforms. It's not necessary to run SPEC on the
final patch, an old run (so long as it's still likely to be valid)
will be OK.
3a. Also, it would be good to run EEMBC on as many platforms (that use
the new scheduler) as possible. Unfortunately, the rules for EEMBC
results are that they may not be published, used in advertising, or
given to non-customers except under NDA, unless they've been
validated by the EEMBC consortium. However, Vlad could send those
results to me, and I can provide them to anyone else who's willing
to agree to a NDA. Vlad, ask me for help running EEMBC if it's not
clear how to do it.
4. Don't forget to do all the usual things: ChangeLog, proper code
formatting, internal documentation, documentation of the new .md
file syntax.
5. I will wait a couple of days before giving the final go-ahead so
that everyone else can comment on the patch---I think that's a good
practise for large changes.
Other than these things, I believe nothing stands in the way of doing
the merge.
--
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>