Re: [PATCH]: GCC Scheduler support for R10000 on MIPS

[Kumba <kumba at gentoo dot org>]

Richard Sandiford wrote:
> Kumba <kumba@gentoo.org> writes:
> > I've sent this up before, but I believe it just got lost in the shuffle.  Is 
> > there anything else that I can do to assist in getting this into GCC?
>
> Hmm.  Out of interest, when did you last submit it?  The last patch
> I could see was:
>
>     http://article.gmane.org/gmane.comp.gcc.patches/109344
>
> which seemed like work in progress rather than a submission.  You said
> you'd submit an updated patch:

Yeah, I was going to do more work in trying to further optimize R10K stuff, 
based on how the R10K manual described it.  Further review pointed out that a 
lot of the further optimizations would offer minimal gain, though.  The patch 
as-is then was a big step in helping GCC schedule code for this processor way 
better than it was originally.

Other things got in the way, though, and it fell by the wayside.  I've got some 
free time now, so I'm aiming to get it cleaned for submission and knock it out 
of the stadium.  I figured, once it's in gcc, it might get some better looking 
at by others and perhaps someone with deeper knowledge of this processor can 
fine-tune it.



>     http://article.gmane.org/gmane.comp.gcc.patches/109444
>
> but I don't remember seeing one, and I can't find any record of it
> in the archives.
>
> Sorry if you've been frustrated by the lack of action here.

Nah, no frustrations.  Just been a lack of time on my part :)


> Have you run the patch through the gcc testsuites?

Not yet.  Are there any quick guides on doing do?  Is that as simple and 
completing a compile, then running 'make test'?


> You had to update some of the types for 4.4, so I assume this should
> include at least 2008.

Updated.

> Needs to be GPLv3.

Ditto.


> I don't think this is useful, given that there was no R10k
> define_functin_unit description in FSF sources.

Yeah, I think I had that blurb there because generic.md was what I modeled off 
of.  The very original patch that started all of this was actually submitted by 
someone else for gcc-3.0 several years ago, and I've pretty much kept forward 
porting it for my own use since.  When DFA was introduced and generic.md got 
split up, that's where this blurb originated from.


> Minor nit, but you've sometimes used many blank lines to separate things.
> Seems a bit excessive: two should be enough.
>
> Coding convention nit: all comments should start with a capital letter
> and end with ".", even if they aren't real sentences.

Cleaned these up -- how does it look now?


> Do you actually model the relationship with the multiplier?  If not,
> it might be worth a comment saying so.

Not real sure.  It's been awhile since I looked at the details, but I know the 
R10K had a rather complex multiplier, and I wasn't real sure how to properly 
model it.  It was also my first stab at DFA and pipeline descriptors in general, 
so there's no telling how far off I was.


> Given that both r10k_fpdiv and r10k_fpsqrt are long-latency insns,
> and that they can be used independently, we might get smaller
> automata if we split r10k_fp into three: r10k_fp, r10k_fpdiv and
> r10k_fpsqrt.  Could you try this and see how it affects the total
> number of states?

I can give this a shot, but memory wants to recall I did have several messages 
to gcc-patches in which I was concerned about the disproportionately high number 
of states that were being generated for one of the automatons (I forget which, I 
think it was the multiplier).  I also wasn't sure of the purpose of automata 
completely, and figured they represented at best, the physically different 
sections of the R10K.  Hence that's how I set them up.

I'll try adding those two additional automata, and tweaking the cpu_units for 
them.  As far as the number of states, is there a quick way to have gcc calc the 
number of states per automata versus actually running the build?

My Octane, which does the building, has a pretty decent 550MHz R14000, but the 
new fractional data types in gcc make a full build take almost 8 hours, which is 
why I ask (unless I can just dump fractional data types)


> "logical" seems to be missing from the .md file.  Should it be in
> this reservation?

I haven't kept track of the newer insns, so I went on ahead and added it here. 
How about signext?  I see that one in the 7000.md file.  Good fit here too?  I 
matched the insns that I could recognize.  'logical', does this refer to 
conditional statements like if clauses and such?


> The way to implement that sort of thing is define_bypass.  E.g.
> make the default latency work for LO, then add a define_bypass that is
> conditional on the int insn using HI.  (I assume that way round would be
> better because using LO is the common case.)  You'd have to use a custom
> predicate, along the lines of mips_store_data_bypass_p.
>
> No need to do that if you don't want, but I think the last sentence is a
> little misleading as it stands.


Hmm, sounds like something to try.  I admit, I know nothing about defining 
custom predicates, though.  Any tips on that?  And does it add much optimization 
to be worth implementing?  The way I was thinking of checking was to use 
lo_operand in one of the define_insn_reservation lines as one of the tests, 
generating one latency if the insn was LO and the other latency if the insn was 
HI in a different define_insn_reservation.  But I wasn't able to find docs that 
explained lo_operand() and what its return values are.  I don't even know if 
it's still around anymore.

So, that comment basically indicates what the R10K manual was saying, and that 
due to lack of understanding lo_operand(), why we weren't attempting to go to 
that level of optimization.  I figured the processor probably won't fuss too 
much about having the same latency on LO or HI, and at best, it's a minor 
deficiency.


> The formatting here looks odd, but maybe it's just mailer mangling.

I'll check the source file to make sure I'm not putting a tab where there are 
plain spaces.  But I am using Thunderbird, if that offers any insight into the 
mangling.  I can attach the file too, if preferred.


> I'd prefer to map r12000, r14000 and r16000 to PROCESSOR_R10000,
> rather than have four PROCESSOR_* values that do the same thing.
> I take your point about leaving processor-specific tuning as
> future work, but I think the split should be introduced as part
> of that work rather than here.

I changed these all to R10000, and removed the R12000-R16000 macros from mips.h. 
 Do I need to remove the separate insn costs from each as well (Except for R10000)?

Also, How does one calculate insn costs?  I never found much detail on that, so 
I think my defaults are copied from something else (been awhile).


> I generally try to avoid having TARGET_* and TUNE_* macros that
> aren't used.  (Again, it's a case of "add it when you need it".)
> There are some old macros that are unused, but still.

I added these mostly so those with an R12000 or R14000 processor can just use 
-march=r12000 and get the same code as an R10K without having to look up the 
info that they need to use -march=r10000.

Should I instead define -march=r1x000?  And later on, when someone can find 
errata for R12K/R14K/R16K, add the processor-specific bits.  Actually, I have an 
R10K manual with R12K notes/errata in it, but none relate to latencies and costs 
as far as I can tell, so I think it's safe for those two processors to be 
replicas of each other.

The R14K's, though, there's no errata documents anywhere that I know of.  SGI's 
likely dumped whatever they have into a black hole somewheres.  The Octane is 
the only Linux-capable box that can run these CPUs anyways, and I'm probably one 
of the few with such a machine.  Mapping it to R10K has worked fine so far.

R16K is on the Tezro's and Origin 3000's only.  Neither has a Linux port yet, 
and that's probably years off.  I only included it for completion, since R16000 
is the last of that line (SGI shelved the R18000).  It's a die shrink of R14000, 
so it probably functions the same, but that's a blind assumption.



Thanks for the feedback!  With the attached patch, I've added most of your 
recommendations except for the LO/HI section.  I've got gcc rebuilding w/ the 
automata changes and I'll see what those state counts are, and see if they match 
up with other mips automata.


Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org


gcc/
    * config/mips/10000.md: Add R10000 scheduler
    * config/mips/mips.c: Add r1x000 params & costs
    * config/mips/mips.h: Add constants
    * config/mips/mips.md: Add r1x000 params & incl 10000.md


diff -Naurp gcc.orig/gcc/config/mips/10000.md gcc/gcc/config/mips/10000.md
--- gcc.orig/gcc/config/mips/10000.md	1969-12-31 19:00:00.000000000 -0500
+++ gcc/gcc/config/mips/10000.md	2008-08-02 13:11:13.000000000 -0400
@@ -0,0 +1,222 @@
+;; DFA-based pipeline description for the VR1x000.
+;;   Copyright (C) 2005, 2006, 2008 Free Software Foundation, Inc.
+;;
+;; This file is part of GCC.
+
+;; GCC is free software; you can redistribute it and/or modify it
+;; under the terms of the GNU General Public License as published
+;; by the Free Software Foundation; either version 3, or (at your
+;; option) any later version.
+
+;; GCC is distributed in the hope that it will be useful, but WITHOUT
+;; ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+;; or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public
+;; License for more details.
+
+;; You should have received a copy of the GNU General Public License
+;; along with GCC; see the file COPYING3.  If not see
+;; <http://www.gnu.org/licenses/>.
+
+
+;; R12K/R14K/R16K are derivatives of R10K, thus copy its description
+;; until specific tuning for each is added.
+
+;; R10000 has int queue, fp queue, address queue.
+;; We split the fp queue into standard fp, fp division, and
+;; fp square root to further optimize the automata, though.
+(define_automaton "r10k_int, r10k_fp, r10k_fpdivision,
+                   r10k_fpsqroot, r10k_addr")
+
+;; R10000 has 2 integer ALUs, fp-adder and fp-multiplier, load/store.
+(define_cpu_unit "r10k_alu1" "r10k_int")
+(define_cpu_unit "r10k_alu2" "r10k_int")
+(define_cpu_unit "r10k_fpadd" "r10k_fp")
+(define_cpu_unit "r10k_fpmpy" "r10k_fp")
+(define_cpu_unit "r10k_loadstore" "r10k_addr")
+
+;; R10000 has separate fp-div and fp-sqrt units as well and these can
+;; execute in parallel, however their issue & completion logic is shared
+;; by the fp-multiplier.
+(define_cpu_unit "r10k_fpdiv" "r10k_fpdivision")
+(define_cpu_unit "r10k_fpsqrt" "r10k_fpsqroot")
+
+
+;; R10k Loader.
+(define_insn_reservation "r10k_load" 2
+  (and (eq_attr "cpu" "r10000,r12000,r14000,r16000")
+       (eq_attr "type" "load,prefetch,prefetchx"))
+  "r10k_loadstore")
+
+(define_insn_reservation "r10k_store" 0
+  (and (eq_attr "cpu" "r10000,r12000,r14000,r16000")
+       (eq_attr "type" "store,fpstore,fpidxstore"))
+  "r10k_loadstore")
+
+(define_insn_reservation "r10k_fpload" 3
+  (and (eq_attr "cpu" "r10000,r12000,r14000,r16000")
+       (eq_attr "type" "fpload,fpidxload"))
+  "r10k_loadstore")
+
+
+;; Integer add/sub + logic ops, and mf/mt hi/lo can be done by alu1 or alu2.
+;; Miscellaneous arith goes here too (this is a guess).
+(define_insn_reservation "r10k_arith" 1
+  (and (eq_attr "cpu" "r10000,r12000,r14000,r16000")
+       (eq_attr "type" "arith,mfhilo,mthilo,slt,clz,const,nop,trap,logical"))
+  "r10k_alu1 | r10k_alu2")
+
+
+;; ALU1 handles shifts, branch eval, and condmove.
+;;
+;; Brancher is separate, but part of ALU1, but can only
+;; do one branch per cycle (needs implementing?).
+;;
+;; Unsure if the brancher handles jumps and calls as well, but since
+;; they're related, we'll add them here for now.
+(define_insn_reservation "r10k_shift" 1
+  (and (eq_attr "cpu" "r10000,r12000,r14000,r16000")
+       (eq_attr "type" "shift,branch,jump,call"))
+  "r10k_alu1")
+
+(define_insn_reservation "r10k_int_cmove" 1
+  (and (eq_attr "cpu" "r10000,r12000,r14000,r16000")
+       (and (eq_attr "type" "condmove")
+            (eq_attr "mode" "SI,DI")))
+  "r10k_alu1")
+
+
+;; Coprocessor Moves.
+;; mtc1/dmtc1 are handled by ALU1.
+;; mfc1/dmfc1 are handled by the fp-multiplier.
+(define_insn_reservation "r10k_mt_xfer" 3
+  (and (eq_attr "cpu" "r10000,r12000,r14000,r16000")
+       (eq_attr "type" "mtc"))
+  "r10k_alu1")
+
+(define_insn_reservation "r10k_mf_xfer" 2
+  (and (eq_attr "cpu" "r10000,r12000,r14000,r16000")
+       (eq_attr "type" "mfc"))
+  "r10k_fpmpy")
+
+
+;; Only ALU2 does int multiplications and divisions.
+;; R10K allows an int insn using register Lo to be issued
+;; one cycle earlier than an insn using register Hi for
+;; the insns below, however, we skip on doing this
+;; for now until correct usage of lo_operand() is figured
+;; out.
+;;
+;; Divides keep ALU2 busy, but this isn't expressed here (I think?).
+(define_insn_reservation "r10k_imul_single" 6
+  (and (eq_attr "cpu" "r10000,r12000,r14000,r16000")
+       (and (eq_attr "type" "imul,imul3,imadd")
+            (eq_attr "mode" "SI")))
+  "r10k_alu2 * 6")
+
+(define_insn_reservation "r10k_imul_double" 10
+  (and (eq_attr "cpu" "r10000,r12000,r14000,r16000")
+       (and (eq_attr "type" "imul,imul3,imadd")
+            (eq_attr "mode" "DI")))
+  "r10k_alu2 * 10")
+
+(define_insn_reservation "r10k_idiv_single" 35
+  (and (eq_attr "cpu" "r10000,r12000,r14000,r16000")
+       (and (eq_attr "type" "idiv")
+            (eq_attr "mode" "SI")))
+  "r10k_alu2 * 35")
+
+(define_insn_reservation "r10k_idiv_double" 67
+  (and (eq_attr "cpu" "r10000,r12000,r14000,r16000")
+       (and (eq_attr "type" "idiv")
+            (eq_attr "mode" "DI")))
+  "r10k_alu2 * 67")
+
+
+;; Floating point add/sub, mul, abs value, neg, comp, & moves.
+(define_insn_reservation "r10k_fp_miscadd" 2
+  (and (eq_attr "cpu" "r10000,r12000,r14000,r16000")
+       (eq_attr "type" "fadd,fabs,fneg,fcmp"))
+  "r10k_fpadd")
+
+(define_insn_reservation "r10k_fp_miscmul" 2
+  (and (eq_attr "cpu" "r10000,r12000,r14000,r16000")
+       (eq_attr "type" "fmul,fmove"))
+  "r10k_fpmpy")
+
+(define_insn_reservation "r10k_fp_cmove" 2
+  (and (eq_attr "cpu" "r10000,r12000,r14000,r16000")
+       (and (eq_attr "type" "condmove")
+            (eq_attr "mode" "SF,DF")))
+  "r10k_fpmpy")
+
+
+;; The fcvt.s.[wl] insn has latency 4, repeat 2.
+;; All other fcvt have latency 2, repeat 1.
+(define_insn_reservation "r10k_fcvt_single" 4
+  (and (eq_attr "cpu" "r10000,r12000,r14000,r16000")
+       (and (eq_attr "type" "fcvt")
+            (eq_attr "cnv_mode" "I2S")))
+  "r10k_fpadd * 2")
+
+(define_insn_reservation "r10k_fcvt_other" 2
+  (and (eq_attr "cpu" "r10000,r12000,r14000,r16000")
+       (and (eq_attr "type" "fcvt")
+            (eq_attr "cnv_mode" "!I2S")))
+  "r10k_fpadd")
+
+
+;; Run the fmadd insn through fp-adder first, then fp-multiplier.
+;;
+;; The latency for fmadd is 2 cycles if the result is used
+;; by another fmadd instruction.
+(define_insn_reservation "r10k_fmadd" 4
+  (and (eq_attr "cpu" "r10000,r12000,r14000,r16000")
+       (eq_attr "type" "fmadd"))
+  "r10k_fpadd, r10k_fpmpy")
+
+(define_bypass 2 "r10k_fmadd" "r10k_fmadd")
+
+
+;; Floating point Divisions & square roots.
+(define_insn_reservation "r10k_fdiv_single" 12
+  (and (eq_attr "cpu" "r10000,r12000,r14000,r16000")
+       (and (eq_attr "type" "fdiv,frdiv")
+            (eq_attr "mode" "SF")))
+  "r10k_fpdiv * 14")
+
+(define_insn_reservation "r10k_fdiv_double" 19
+  (and (eq_attr "cpu" "r10000,r12000,r14000,r16000")
+       (and (eq_attr "type" "fdiv,frdiv")
+            (eq_attr "mode" "DF")))
+  "r10k_fpdiv * 21")
+
+(define_insn_reservation "r10k_fsqrt_single" 18
+  (and (eq_attr "cpu" "r10000,r12000,r14000,r16000")
+       (and (eq_attr "type" "fsqrt")
+            (eq_attr "mode" "SF")))
+  "r10k_fpsqrt * 20")
+
+(define_insn_reservation "r10k_fsqrt_double" 33
+  (and (eq_attr "cpu" "r10000,r12000,r14000,r16000")
+       (and (eq_attr "type" "fsqrt")
+            (eq_attr "mode" "DF")))
+  "r10k_fpsqrt * 35")
+
+(define_insn_reservation "r10k_frsqrt_single" 30
+  (and (eq_attr "cpu" "r10000,r12000,r14000,r16000")
+       (and (eq_attr "type" "frsqrt")
+            (eq_attr "mode" "SF")))
+  "r10k_fpsqrt * 20")
+
+(define_insn_reservation "r10k_frsqrt_double" 52
+  (and (eq_attr "cpu" "r10000,r12000,r14000,r16000")
+       (and (eq_attr "type" "frsqrt")
+            (eq_attr "mode" "DF")))
+  "r10k_fpsqrt * 35")
+
+
+;; Handle unknown/multi insns here (this is a guess).
+(define_insn_reservation "r10k_unknown" 1
+  (and (eq_attr "cpu" "r10000,r12000,r14000,r16000")
+       (eq_attr "type" "unknown,multi"))
+  "r10k_alu1 + r10k_alu2")
diff -Naurp gcc.orig/gcc/config/mips/mips.c gcc/gcc/config/mips/mips.c
--- gcc.orig/gcc/config/mips/mips.c	2008-08-01 21:55:41.000000000 -0400
+++ gcc/gcc/config/mips/mips.c	2008-08-02 12:13:48.000000000 -0400
@@ -593,6 +593,10 @@ static const struct mips_cpu_info mips_c

   /* MIPS IV processors. */
   { "r8000", PROCESSOR_R8000, 4, 0 },
+  { "r10000", PROCESSOR_R10000, 4, 0 },
+  { "r12000", PROCESSOR_R10000, 4, 0 },
+  { "r14000", PROCESSOR_R10000, 4, 0 },
+  { "r16000", PROCESSOR_R10000, 4, 0 },
   { "vr5000", PROCESSOR_R5000, 4, 0 },
   { "vr5400", PROCESSOR_R5400, 4, 0 },
   { "vr5500", PROCESSOR_R5500, 4, PTF_AVOID_BRANCHLIKELY },
@@ -988,6 +992,58 @@ static const struct mips_rtx_cost_data m
 		     1,           /* branch_cost */
 		     4            /* memory_latency */
   },
+  { /* R10000 */
+    COSTS_N_INSNS (2),            /* fp_add */
+    COSTS_N_INSNS (2),            /* fp_mult_sf */
+    COSTS_N_INSNS (2),            /* fp_mult_df */
+    COSTS_N_INSNS (12),           /* fp_div_sf */
+    COSTS_N_INSNS (19),           /* fp_div_df */
+    COSTS_N_INSNS (6),            /* int_mult_si */
+    COSTS_N_INSNS (10),           /* int_mult_di */
+    COSTS_N_INSNS (35),           /* int_div_si */
+    COSTS_N_INSNS (67),           /* int_div_di */
+		     1,           /* branch_cost */
+		     4            /* memory_latency */
+  },
+  { /* R12000 */
+    COSTS_N_INSNS (2),            /* fp_add */
+    COSTS_N_INSNS (2),            /* fp_mult_sf */
+    COSTS_N_INSNS (2),            /* fp_mult_df */
+    COSTS_N_INSNS (12),           /* fp_div_sf */
+    COSTS_N_INSNS (19),           /* fp_div_df */
+    COSTS_N_INSNS (6),            /* int_mult_si */
+    COSTS_N_INSNS (10),           /* int_mult_di */
+    COSTS_N_INSNS (35),           /* int_div_si */
+    COSTS_N_INSNS (67),           /* int_div_di */
+		     1,           /* branch_cost */
+		     4            /* memory_latency */
+  },
+  { /* R14000 */
+    COSTS_N_INSNS (2),            /* fp_add */
+    COSTS_N_INSNS (2),            /* fp_mult_sf */
+    COSTS_N_INSNS (2),            /* fp_mult_df */
+    COSTS_N_INSNS (12),           /* fp_div_sf */
+    COSTS_N_INSNS (19),           /* fp_div_df */
+    COSTS_N_INSNS (6),            /* int_mult_si */
+    COSTS_N_INSNS (10),           /* int_mult_di */
+    COSTS_N_INSNS (35),           /* int_div_si */
+    COSTS_N_INSNS (67),           /* int_div_di */
+		     1,           /* branch_cost */
+		     4            /* memory_latency */
+  },
+  { /* R16000 */
+    COSTS_N_INSNS (2),            /* fp_add */
+    COSTS_N_INSNS (2),            /* fp_mult_sf */
+    COSTS_N_INSNS (2),            /* fp_mult_df */
+    COSTS_N_INSNS (12),           /* fp_div_sf */
+    COSTS_N_INSNS (19),           /* fp_div_df */
+    COSTS_N_INSNS (6),            /* int_mult_si */
+    COSTS_N_INSNS (10),           /* int_mult_di */
+    COSTS_N_INSNS (35),           /* int_div_si */
+    COSTS_N_INSNS (67),           /* int_div_di */
+		     1,           /* branch_cost */
+		     4            /* memory_latency */
+  },
   { /* SB1 */
     /* These costs are the same as the SB-1A below.  */
     COSTS_N_INSNS (4),            /* fp_add */
@@ -9872,7 +9928,10 @@ mips_issue_rate (void)
 	 but in reality only a maximum of 3 insns can be issued as
 	 floating-point loads and stores also require a slot in the
 	 AGEN pipe.  */
-     return 4;
+    case PROCESSOR_R10000:
+      /* All R10K Processors are quad-issue (being the first MIPS
+         processors to support this feature). */
+      return 4;

     case PROCESSOR_20KC:
     case PROCESSOR_R4130:
diff -Naurp gcc.orig/gcc/config/mips/mips.h gcc/gcc/config/mips/mips.h
--- gcc.orig/gcc/config/mips/mips.h	2008-08-01 21:55:41.000000000 -0400
+++ gcc/gcc/config/mips/mips.h	2008-08-02 12:14:38.000000000 -0400
@@ -66,6 +66,7 @@ enum processor_type {
   PROCESSOR_R7000,
   PROCESSOR_R8000,
   PROCESSOR_R9000,
+  PROCESSOR_R10000,
   PROCESSOR_SB1,
   PROCESSOR_SB1A,
   PROCESSOR_SR71000,
@@ -241,6 +242,10 @@ enum mips_code_readable_setting {
 #define TARGET_MIPS5500             (mips_arch == PROCESSOR_R5500)
 #define TARGET_MIPS7000             (mips_arch == PROCESSOR_R7000)
 #define TARGET_MIPS9000             (mips_arch == PROCESSOR_R9000)
+#define TARGET_MIPS10000            (mips_arch == PROCESSOR_R10000)
+#define TARGET_MIPS12000            (mips_arch == PROCESSOR_R10000)
+#define TARGET_MIPS14000            (mips_arch == PROCESSOR_R10000)
+#define TARGET_MIPS16000            (mips_arch == PROCESSOR_R10000)
 #define TARGET_SB1                  (mips_arch == PROCESSOR_SB1		\
 				     || mips_arch == PROCESSOR_SB1A)
 #define TARGET_SR71K                (mips_arch == PROCESSOR_SR71000)
@@ -267,6 +272,10 @@ enum mips_code_readable_setting {
 #define TUNE_MIPS6000               (mips_tune == PROCESSOR_R6000)
 #define TUNE_MIPS7000               (mips_tune == PROCESSOR_R7000)
 #define TUNE_MIPS9000               (mips_tune == PROCESSOR_R9000)
+#define TUNE_MIPS10000              (mips_tune == PROCESSOR_R10000)
+#define TUNE_MIPS12000              (mips_tune == PROCESSOR_R10000)
+#define TUNE_MIPS14000              (mips_tune == PROCESSOR_R10000)
+#define TUNE_MIPS16000              (mips_tune == PROCESSOR_R10000)
 #define TUNE_SB1                    (mips_tune == PROCESSOR_SB1		\
 				     || mips_tune == PROCESSOR_SB1A)

diff -Naurp gcc.orig/gcc/config/mips/mips.md gcc/gcc/config/mips/mips.md
--- gcc.orig/gcc/config/mips/mips.md	2008-08-01 21:55:41.000000000 -0400
+++ gcc/gcc/config/mips/mips.md	2008-08-01 23:05:01.000000000 -0400
@@ -553,7 +553,7 @@
 ;; Attribute describing the processor.  This attribute must match exactly
 ;; with the processor_type enumeration in mips.h.
 (define_attr "cpu"
- 
"r3000,4kc,4kp,5kc,5kf,20kc,24kc,24kf2_1,24kf1_1,74kc,74kf2_1,74kf1_1,74kf3_2,loongson_2e,loongson_2f,m4k,r3900,r6000,r4000,r4100,r4111,r4120,r4130,r4300,r4600,r4650,r5000,r5400,r5500,r7000,r8000,r9000,sb1,sb1a,sr71000,xlr"
+ 
"r3000,4kc,4kp,5kc,5kf,20kc,24kc,24kf2_1,24kf1_1,74kc,74kf2_1,74kf1_1,74kf3_2,loongson_2e,loongson_2f,m4k,r3900,r6000,r4000,r4100,r4111,r4120,r4130,r4300,r4600,r4650,r5000,r5400,r5500,r7000,r8000,r9000,r10000,r12000,r14000,r16000,sb1,sb1a,sr71000,xlr"
   (const (symbol_ref "mips_tune")))

 ;; The type of hardware hazard associated with this instruction.
@@ -903,6 +903,7 @@
 (include "6000.md")
 (include "7000.md")
 (include "9000.md")
+(include "10000.md")
 (include "sb1.md")
 (include "sr71k.md")
 (include "xlr.md")