On Mon, Oct 14, 2019 at 05:12:56PM -0400, Michael Meissner wrote:
> On Thu, Oct 10, 2019 at 05:02:09PM -0500, Segher Boessenkool wrote:
> > > @@ -7786,8 +7790,12 @@ (define_insn_and_split "*movtd_64bit_nod
> > > "#"
> > > "&& reload_completed"
> > > [(pc)]
> > > -{ rs6000_split_multireg_move (operands[0], operands[1]); DONE; }
> > > - [(set_attr "length" "8,8,8,12,12,8")])
> > > +{
> > > + rs6000_split_multireg_move (operands[0], operands[1]);
> > > + DONE;
> > > +}
> > > + [(set_attr "non_prefixed_length" "8")
> > > + (set_attr "prefixed_length" "20")])
> >
> > It used to be 8,8,8,12,12,8 before. Was that in error? Please explain.
>
> We've had this discussion before, but I didn't update the ChangeLog.
>
> The two cases for 12 bytes (i.e. 3 insns) are r->Y and Y->r constaints. Y
> matches DS offsets (i.e. bottom 2 bits non-zero) for traditional instructions.
> In looking at rs6000_split_multireg_move, the only way I can see that 3
> instructions would be generated would be if pre_modify/pre_update/etc. were
> generated. But we don't allow pre_modify on larger types.
So do this as a separate change, first, please?
If it cannot happen, please also add an assert (somewhere early, before
doing anything else with the automodifies), an remove any now-dead code
(if there is any).
> But if you think there might be a case where it does generate 3 instructions,
> I
> can modify it to use 8,8,8,12,12,8 for the non-prefixed case, and
> 20,20,20,24,24,20 for the prefixed case.
I think you are right, but it's not obvious, and it warrants a separate
patch. That way, we can easily bisect it if some problem manifests, etc.
Thanks,
Segher
