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]

RFC: mips SB-1 DFA scheduler


I have written a DFA scheduler for the Broadcom MIPS SB-1 part for a customer.
There are some issues that need to be discussed about this patch.

This is a patch off of the 3.4.x release branch from about a month ago.  I used
the 3.4.x branch because it is what we gave to the customer.  It would be
nice to get this into 3.4, but I won't demand it.  I realize that it is getting
a bit late to putting stuff in the release.

The main issue with this patch is that I need a lot more instruction types
than are currently defined in the mips.md file.  See the sb_type attribute
I added to the mips.md file.  This was a temporary solution, to reduce the
amount of changes I made.  If it is OK, I would suggest splitting up the
existing type attributes so as to get the ones I need.  This will require
changes to the other DFA description files.  Or if you prefer, I could add
the sb_type attribute.  I need arith split into arith/shift/slt/clz.  I need
fpload/fpstore separated from load/store.  Also, I need the fp indexed loads
and stores separated out.  I can submit separate patches for these changes.

I noticed some inconsistencies with the existing type attribute.  There is a
nop type, but the nop instruction does not use it.  There is a icmp type, but
there are no instructions that use it, only mips16 has an actual integer
compare instruction.  The darith type does not seem to serve any useful
purpose.  All DFA schedulers that need to distinguish between 32-bit and 64-bit
operations check the mode attribute.  In most cases, arith and darith are
handled identically in the schedulers.  darith only occurs for 64-bit targets,
in which case it will be a single instruction.  But since arith is also a
single instruction, having darith does not seem to gain anything, it could just
as well be arith.

Another way to distinguish between instruction types is to look at the
operands.  I did this in two cases, for no real reason.  See the lo_operand
and fp_register_operand functions I added.  I use lo_operand to distinguish
mfhi/mthi from mflo/mfhi.  But this could alternatively be handled by splitting
the hilo instruction type into 4 types, mfhi/mthi/mflo/mfhi.    The function
fp_register_operand was added to I could distinguish ctc1 from cfc1, which
are both type xfer currently.  This could also be fixed by splitting xfer
into two types, xfert and xferf for instance.  Adding extra types is more
efficient than adding extra predicate calls to the scheduler.

There is another unrelated issue with FP exceptions.  The SB-1 has two FP pipes
but only one can be used when FP exceptions are enabled.  This is the normal
case for linux, but some users will turn them off, and there is no way for the
compiler to know if they are on or not.  This makes a significant difference
in the performance of the resulting code.   So I added an option for the user
to specify this, -msb1-fp-exceptions={on,off}.  This is clumsy, but I didn't
see a better way to do this.  I am missing docs for this new option, which I
will write before this patch gets resubmitted.

Most of the rest of the patch I expect is non-controversial.  The mips_{ld,st}_
address_bypass_p were borrowed from the IA-64 port.  They allow me to detect
whether an alu instruction result is used as an address or a data input to
a load/store.  These have different latencies.

I am willing to make changes requested by the MIPS maintainers.

This patch has been tested on hardware, mainly using byte benchmarks because
they are conveniently small.  I will be testing with better benchmarks such
as spec95 and spec2000 shortly.  I may make some more tuning changes, but I
don't expect to make any more significant changes to this patch.

Using the byte benchmarks, I get speedups of about 3-7%, but this is a
comparison against a compiler with no SB-1 scheduling support.  If I compare
against -mtune=sr71k/-mtune=rm9000, then I get about 1-3%.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Attachment: patch.sb1.dfa
Description: Text document


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