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> Paul Koning wrote:
 >> If we have four issue slots to fill, don't we want to look ahead a
 >> fair amount MORE than 4 insns to find the four that are the best
 >> choices to issue right now?  (If that's not what this "lookahead"
 >> thing is meant to do, its docs could stand some improvement.)  I
 >> wonder if that accounts for the fact that you didn't see an
 >> improvement with an issue_rate of 4, as one would expect.

 Jim> If you look at every target that uses the lookahead parameter,
 Jim> it is set to the number of instructions that can be issued per
 Jim> cycle.  The IA-64 port in particular does it this way, and the
 Jim> IA-64 DFA scheduler was written by Vlad who ought to know, so
 Jim> clearly this is the way it is intended to be used.  I haven't
 Jim> looked at the details of what this actually does, so I can't
 Jim> comment on whether using a larger number would be more helpful.

I last looked at the doc for this when the DFA scheduler was in
development on the DFA branch, which is a while ago.  I can't find my
correspondence about it anymore (if I had any -- I think I did).  The
documentation wasn't particularly clear back then and still isn't.

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? 

The wording of the comment on that hook in your scheduler seems to say
roughly the same thing as my reading of the docs...

 >> Out of curiosity, does this use any of the DFA scheduling work I
 >> did?  I guess it doesn't; looking back at what Chris posted a
 >> while back, that was only the bare skeleton.

 Jim> I don't know what you are referring to.  I wrote this all from
 Jim> scratch. If there is previous work, I can take a look at it.  I
 Jim> saw a non-DFA scheduler for SB-1 in some old Broadcom tools
 Jim> releases, but I don't know about any previous DFA scheduler work
 Jim> for the SB-1.

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

I did get it running at one point (on dfa_branch and, I think, on
mainline shortly after dfa_branch was merged).  I didn't submit it
because of NDA issues, that's why it eventually was contributed by way
of Chris Demetriou.  That email message seems to contain only the core
piece, though -- and certainly there's a lot more in what you have
submitted. 

	   paul



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