Maciej Rozycki <maciej.rozy...@imgtec.com> writes:
> On Fri, 23 Jun 2017, Prachi Godbole wrote:
>
> > Index: gcc/config/mips/mips.md
> > ===================================================================
> > --- gcc/config/mips/mips.md (revision 246899)
> > +++ gcc/config/mips/mips.md (working copy)
> > @@ -6578,6 +6581,20 @@
> > [(set_attr "type" "jump")
> > (set_attr "mode" "none")])
> >
> > +;; Insn to clear execution and instruction hazards while returning.
> > +;; However, it doesn't clear hazards created by the insn in its delay
> slot.
> > +;; Thus, explicitly place a nop in its delay slot.
> > +
> > +(define_insn "mips_hb_return_internal"
> > + [(return)
> > + (unspec_volatile [(match_operand 0 "pmode_register_operand" "")]
> > + UNSPEC_JRHB)]
> > + ""
> > + {
> > + return "%(jr.hb\t$31%/%)";
> > + }
> > + [(set_attr "insn_count" "2")])
> > +
> > ;; Normal return.
> >
> > (define_insn "<optab>_internal"
>
> Nothing wrong with your proposed change, but overall I wonder if (as a
> follow-up change) we could find a nonintrusive way to have this pattern
> (and `clear_hazard_<mode>' as well) produce JRS.HB rather than JR.HB in
> microMIPS compilations, as using the 32-bit delay-slot NOP encoding
> where the 16-bit one would do is obviously a tiny, but completely
> unnecessary code space loss (and we do care about code space losses in
> microMIPS compilations; conserving space is the very purpose of the
> microMIPS ISA after all).
>
> Of course it wouldn't do if we rewrote the instruction pattern as
> "%(jr%!.hb\t$31%/%)" here, because the NOP that follows would have to
> come from an RTL instruction for `%!' to have any effect. But perhaps
> we could emit RTL instead somehow rather than hardcoding the NOP with
> `%/'?
I think this case is so specialist we can safely just switch to writing
out the NOP directly in the output pattern just keeping the %(%) for
noreorder. This code will have to be reworked with microMIPSR6 when
submitted so it can be handled then; good spot to use jrs.hb.
Thanks,
Matthew
