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