This is the mail archive of the gcc-patches@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: RFC: mips SB-1 DFA scheduler


>>>>> "Jim" == Jim Wilson <wilson@specifixinc.com> writes:

 Jim> On Thu, 2004-03-04 at 06:57, Paul Koning wrote:
 >> My best interpretation is that this hook says how far to look
 >> ahead in the queue of ready instructions to find the ones that
 >> will be issued this cycle.  And it seems pretty obvious that you
 >> can't rearrange instruction issue for a quad issue machine unless
 >> you look at substantially MORE than 4 ready instructions, right?
 >> Otherwise you're basically just issuing FIFO.  That can't be
 >> right.  So what am I missing?

 Jim> A number of target files that define the lookahead hook claim
 Jim> that it is a measure of the scheduling freedom in the DFA.  This
 Jim> is the interpretation that I am using. ...

 Jim> lookahead isn't the number of instructions we look at on the
 Jim> ready queue.  There is a comment in haifa-sched.c...

Thanks, that helps.  I learned DFA from the gccint documentation, such
as it is.  It's actually rather detailed by comparison with most of
the rest of the gcc internals documentation, but even so it leaves a
bunch of questions -- such as this one -- to the imagination.

 Jim> If it is just the comment that you find confusing, then I can
 Jim> fix that. I could replace the current wording with the
 Jim> "scheduling freedom" wording that is found in other files.

That sounds like a good idea.

 >> You can find it here:
 >> http://gcc.gnu.org/ml/gcc-patches/2003-02/msg01505.html

 Jim> Thanks.  I wasn't aware of this.  It looks like Eric asked Chris
 Jim> to indicate when it was finished, and Chris never said it was
 Jim> finished, so it never got checked in.

Correct, and I don't know if Chris or his colleagues have had a chance
to work on this further.

 Jim> The handling of simple alu instructions appears to be wrong.
 Jim> There are two define_insn_reservation's that match simple alu
 Jim> instructions, but the docs say that the result is undefined when
 Jim> you do this.  There needs to be a single
 Jim> define_insn_reservation.  Unfortunately, this means we can't get
 Jim> the latencies right, at least not without a lot of extra work
 Jim> that I don't plan to do.

I ran into problems there but I don't remember if I realized the
cause, i.e., the undefined part.  Part of the puzzle is what rules the
SB-1 uses to decide to issue an instruction to the LS1 pipe rather
than the EXEn pipes.

This might be an area worth future work, because it seems that it
could make the difference between triple and quad issue in some
cases. 

 Jim> ...Otherwise, they look similar, except that mine has a lot more
 Jim> detail.

 Jim> If you have any empirical results that show that this DFA
 Jim> scheduler gives better code than the one I offered, then I would
 Jim> be interested in seeing that.  I would hope that mine works
 Jim> better because it has more detail.

I don't have data for that, unfortunately.  Creating it would likely
be a significant job because that code hasn't been touched in quite
some time, so it's not up to date with the gcc core.  Based on the
comparison you did I'm ready to believe that yours should be the
better description.

       paul


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