RE: DFA scheduler merge - approval issues?

RE: DFA scheduler merge - approval issues?

[Naveen Sharma, Noida]

>    > Other than these things, I believe nothing stands in the 
> way of doing
>    > the merge.
>    
>    Thanks, Geoff.  I'll do it.  I think that I could finish 
> it in week.
> 
> I will help with regression testing on Sparc.
> 
> As per the SPEC result stuff, there was a posting showing the
> SPEC improvements DFA alone gave on UltraSPARC, but I cannot
> remember if it was posted to these lists or not.

I can help with any additional testing of the merged code on sh4.

Best Regards,
  Naveen Sharma.  

Re: DFA scheduler merge - approval issues?

[law]

In message <3CB4A0AB.F3F4D76F@st.com>, Stephen Clarke writes:
 > vmakarov@redhat.com wrote:
 > > 
 > > Thanks, Geoff.  I'll do it.  I think that I could finish it in week.
 > 
 > For which targets do you plan to enable DFA scheduling?
 > 
 > IIRC, the SH-4 specific work was done by Noida, so will that
 > be a separate patch once the main DFA patch has been accepted?  Or
 > will you include it in your patch?
Also note I'll contribute my PA7100 DFA definition (generates 100% identical
code when compared to existing scheduler definition) and my PA8000 DFA 
definition which generates slightly better code than the existing scheduler
definition.  I have not had time to track down a PA7100LC machine for testing
a PA7100LC description.

jeff

Re: DFA scheduler merge - approval issues?

[David S. Miller]

   From: Vladimir Makarov <vmakarov@redhat.com>
   Date: Wed, 10 Apr 2002 14:55:50 -0400

   > Other than these things, I believe nothing stands in the way of doing
   > the merge.
   
   Thanks, Geoff.  I'll do it.  I think that I could finish it in week.

I will help with regression testing on Sparc.

As per the SPEC result stuff, there was a posting showing the
SPEC improvements DFA alone gave on UltraSPARC, but I cannot
remember if it was posted to these lists or not.

Re: DFA scheduler merge - approval issues?

[David S. Miller]

   From: Vladimir Makarov <vmakarov@redhat.com>
   Date: Wed, 10 Apr 2002 16:39:22 -0400

   The patch will include all code added into the branch (I asked
   permission to merge the branch).  Currently, it is dfa-based scheduler
   itself and code (dfa descriptions) to use dfa-scheduler for ultrasparc
   and sh4.

Not just UltraSparc, both UltraSparc-I/II and UltraSparc-III :-)

UltraSPARC-III required entirely different pipeline description
from it's predecessors.  Actually, it was more simple to model,
as it has less instruction issue restrictions.

Re: DFA scheduler merge - approval issues?

[David S. Miller]

   From: Vladimir Makarov <vmakarov@redhat.com>
   Date: Wed, 10 Apr 2002 15:25:31 -0400

   >         Is the software pipelining optimization which relies on the DFA
   > scheduler ready as well?
   
   Why should it be ready to merge the dfa-based scheduler?  The bigger
   patch, the harder to merge it.  My plan is to merge the dfa-based
   scheduler into the main trunk and after that use the branch to work on
   software pipelining and may be a new interblock insn scheduler.

I agree with Vladimir, software pipelining should need to be available
as a prerequisite for DFA merging.  It would only complicate matters.

Re: DFA scheduler merge - approval issues?

[Geoff Keating]

> Date: Wed, 10 Apr 2002 15:25:31 -0400
> From: Vladimir Makarov <vmakarov@redhat.com>

> David Edelsohn wrote:
> >         Is the software pipelining optimization which relies on the DFA
> > scheduler ready as well?
> 
> Why should it be ready to merge the dfa-based scheduler?  The bigger
> patch, the harder to merge it.  My plan is to merge the dfa-based
> scheduler into the main trunk and after that use the branch to work on
> software pipelining and may be a new interblock insn scheduler.

Yes, I agree.  In fact, even if software pipelining was ready now, I
would prefer that you submit it separately if possible.

-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>

Re: DFA scheduler merge - approval issues?

[Vladimir Makarov]

Stephen Clarke wrote:
> 
> vmakarov@redhat.com wrote:
> >
> > Thanks, Geoff.  I'll do it.  I think that I could finish it in week.
> 
> For which targets do you plan to enable DFA scheduling?
> 
> IIRC, the SH-4 specific work was done by Noida, so will that
> be a separate patch once the main DFA patch has been accepted?  Or
> will you include it in your patch?

The patch will include all code added into the branch (I asked
permission to merge the branch).  Currently, it is dfa-based scheduler
itself and code (dfa descriptions) to use dfa-scheduler for ultrasparc
and sh4.

Vlad

Re: DFA scheduler merge - approval issues?

[Stephen Clarke]

vmakarov@redhat.com wrote:
> 
> Thanks, Geoff.  I'll do it.  I think that I could finish it in week.

For which targets do you plan to enable DFA scheduling?

IIRC, the SH-4 specific work was done by Noida, so will that
be a separate patch once the main DFA patch has been accepted?  Or
will you include it in your patch?

Steve.

Re: DFA scheduler merge - approval issues?

[Vladimir Makarov]

David Edelsohn wrote:
> 
> >>>>> Geoff Keating writes:
> 
> Geoff> 3. Since this is about performance, some performance statistics should
> Geoff> be provided.  I believe Vlad has some SPEC results, which would be
> Geoff> good to provide in the message; in particular, it's important that
> Geoff> the patch doesn't cause performance to significantly decrease on
> Geoff> any platform (I'm thinking of powerpc), even if it only provides a
> Geoff> benefit for some platforms.  It's not necessary to run SPEC on the
> Geoff> final patch, an old run (so long as it's still likely to be valid)
> Geoff> will be OK.
> 
>         How does the DFA scheduler impact the time it takes to compile a
> program relative to the current scheduler?
> 

  David, the dfa-based scheduler should be not slower than the current
one especially for processors with complicated pipeline characteristics
if we do not use multipass insn scheduling.  The multipass scheduling
tries permutations of queue of insns ready to issue.   It improves code
slightly.  The current scheduler does not implement the multipass
scheduling.  We could implement it for the current scheduler but it will
be much slower than the code using the dfa-based description.  In any
case, I'll check the time too.  If we have a compilation speed
degradation we could switch on the multipass scheduling only for -O3.

   I am working on dfa-based scheduler for ia64.  It is a big work. 
There are a lot of code already written for tuning the current
scheduler.  I've just recently made a preliminary automaton description
of itanium and switched on its usage for the 1st insn scheduling.  I've
tried it on several small tests.  There is no visible degradation in
code quality or significant changes in the generated code size, but the
compiler works faster on 10-15%.  In these experiments I did not use the
multipass scheduler.

>         Is the software pipelining optimization which relies on the DFA
> scheduler ready as well?

Why should it be ready to merge the dfa-based scheduler?  The bigger
patch, the harder to merge it.  My plan is to merge the dfa-based
scheduler into the main trunk and after that use the branch to work on
software pipelining and may be a new interblock insn scheduler.

Vlad

Re: DFA scheduler merge - approval issues?

[Vladimir Makarov]

Geoff Keating wrote:
> 
> 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.

Thanks, Geoff.  I'll do it.  I think that I could finish it in week.

Vlad

Re: DFA scheduler merge - approval issues?

[David Edelsohn]

>>>>> Geoff Keating writes:

Geoff> 3. Since this is about performance, some performance statistics should
Geoff> be provided.  I believe Vlad has some SPEC results, which would be
Geoff> good to provide in the message; in particular, it's important that
Geoff> the patch doesn't cause performance to significantly decrease on
Geoff> any platform (I'm thinking of powerpc), even if it only provides a
Geoff> benefit for some platforms.  It's not necessary to run SPEC on the
Geoff> final patch, an old run (so long as it's still likely to be valid)
Geoff> will be OK.

	How does the DFA scheduler impact the time it takes to compile a
program relative to the current scheduler?

	Is the software pipelining optimization which relies on the DFA
scheduler ready as well? 

David

Re: DFA scheduler merge - approval issues?

[Geoff Keating]

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>

Re: DFA scheduler merge - approval issues?

[Daniel Berlin]

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.

Vlad, does it still bootstrap/cause no regressions?

> 
> I'm highly interested in this because the DFA scheduler performs
> extremely well on the SH4; with the modifications, I'm seeing GCC produce
> code which can be reasonably compared to hand-coded SH4 assembly.
> 
> Is there anything which I (or other people) can do to facilitate and/or
> expedite the approval process?
> 
> Toshi
> 
> 
> 
> 
> 
> 

DFA scheduler merge - approval issues?

[tm]

I'm wondering what issues are preventing the DFA scheduler from being
approved for inclusion into the mainline source?

I'm highly interested in this because the DFA scheduler performs
extremely well on the SH4; with the modifications, I'm seeing GCC produce
code which can be reasonably compared to hand-coded SH4 assembly.

Is there anything which I (or other people) can do to facilitate and/or
expedite the approval process?

Toshi