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]

Re: DFA scheduler merge - approval issues?


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>


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