Chung-Lin Tang <clt...@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
