Re: [PATCH][MIPS] NetLogic XLP scheduling

[Richard Sandiford <rdsandiford at googlemail dot com>]

Chung-Lin Tang <cltang@codesourcery.com> writes:
>>> Other generic changes include a new "hilo" insn attribute, to mark which
>>> of HI/LO does a m[ft]hilo insn access.
>> 
>> The way other schedulers handle this is with things like:
>> 
>> (define_insn_reservation "ir_sb1_mfhi" 1
>>   (and (eq_attr "cpu" "sb1,sb1a")
>>        (and (eq_attr "type" "mfhilo")
>> 	    (not (match_operand 1 "lo_operand"))))
>>   "sb1_ex1")
>> 
>> which seems simpler.  mfhilo and mthilo are required to read operand 1
>> and write to operand 0 (respectively) in order to support this kind of
>> construct.
>> 
>> That said, even the above is a hold-over from when we tried to allow
>> high registers to store independent values.  These days we can be a bit
>> more precise, as with the patch below.  (As the comment says:
>> 
>> 	 ;; If a doubleword move uses these expensive instructions,
>> 	 ;; it is usually better to schedule them in the same way
>> 	 ;; as the singleword form, rather than as "multi".
>> 
>> I'm continuing to assume that mflo and mtlo are the best type choices
>> for unsplit double-register moves.  That path should be very rarely
>> outside of MIPS16 anyway -- just by sched1 if hi and lo are exposed
>> directly -- and no current scheduler tries to model a doubleword hi/lo
>> move separately from single-register ones.  The information is available
>> via the dword_mode attribute if required.)
>
> I suppose this means that actual generation of moves as mfhi/mthi should
> almost never happen out of normal conditions?

Yeah, the move patterns themselves never generate mfhi or mthi in isolation.
They either generate mflo, mtlo, mfhi+mflo, or mthi+mtlo.  mfhi and mthi
have special patterns that are generated by post-reload splits.

Richard