This is the mail archive of the
mailing list for the GCC project.
Re: RFC: mips SB-1 DFA scheduler
>>>>> "Jim" == Jim Wilson <email@example.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:
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
Jim> ...Otherwise, they look similar, except that mine has a lot more
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