Re: RFC: mips SB-1 DFA scheduler

[Richard Sandiford <rsandifo at redhat dot com>]

Jim Wilson <wilson@specifixinc.com> writes:
> 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 definitely prefer your suggestion of splitting the existing types.
The attribute is only really there for the schedulers' benefit and
it has tended to evolve as new distinctions are needed.  Since all
you'll be doing is replacing single types with several subtypes,
I'd expect the changes to the other DFAs to be fairly mechanical.

Personally, I don't have an opinion (at least not yet ;) on whether
this is too invasive for 3.4.

> 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.

Sounds good.

> I noticed some inconsistencies with the existing type attribute.

Yeah, tell me about it ;)

> 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.  [...]

Right.  Plus there's the somewhat pointless use of "move" rather than
"arith" for GPR->GPR moves.  I think we should just use collapse GPR->GPR
moves, nop, icmp, arith, and darith into a single type and use something
like "fmove" for FPR->FPR moves.  It's been on my long-term to-do list,
but I never got around to it...

> 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.

Sounds like we should bite the bullet and do the split.  The rm7000 and
rm9000 schedulers use a similar trick and I've some local vr5500 patches
that need it too.

> 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.

Do you mean mtc1 and mfc1?  I don't think gcc uses ctc1 and cfc1.
IMO, mtc1 and mfc1 (or perhaps mtc and mfc) would be better names
for the new types.

> 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.

FWIW, I've no problem with that.

> 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.

Since two ports need this, wouldn't it be better to move the code out
of the back ends?

Richard