On Mon, Jun 24, 2024 at 10:03 AM Richard Sandiford
<richard.sandif...@arm.com> wrote:
>
> Richard Biener <richard.guent...@gmail.com> writes:
> > On Sat, Jun 22, 2024 at 6:50 PM Richard Sandiford
> >> The traditional (and IMO correct) way to handle this is to make the
> >> pattern reserve the temporary registers that it needs, using
> >> match_scratches.
> >> rs6000 has many examples of this. E.g.:
> >>
> >> (define_insn_and_split "@ieee_128bit_vsx_neg<mode>2"
> >> [(set (match_operand:IEEE128 0 "register_operand" "=wa")
> >> (neg:IEEE128 (match_operand:IEEE128 1 "register_operand" "wa")))
> >> (clobber (match_scratch:V16QI 2 "=v"))]
> >> "TARGET_FLOAT128_TYPE && !TARGET_FLOAT128_HW"
> >> "#"
> >> "&& 1"
> >> [(parallel [(set (match_dup 0)
> >> (neg:IEEE128 (match_dup 1)))
> >> (use (match_dup 2))])]
> >> {
> >> if (GET_CODE (operands[2]) == SCRATCH)
> >> operands[2] = gen_reg_rtx (V16QImode);
> >>
> >> emit_insn (gen_ieee_128bit_negative_zero (operands[2]));
> >> }
> >> [(set_attr "length" "8")
> >> (set_attr "type" "vecsimple")])
> >>
> >> Before RA, this is just:
> >>
> >> (set ...)
> >> (clobber (scratch:V16QI))
> >>
> >> and the split creates a new register. After RA, operand 2 provides
> >> the required temporary register:
> >>
> >> (set ...)
> >> (clobber (reg:V16QI TMP))
> >>
> >> Another approach is to add can_create_pseudo_p () to the define_insn
> >> condition (rather than the split condition). But IMO that's an ICE
> >> trap, since insns that have already been matched & accepted shouldn't
> >> suddenly become invalid if recog is reattempted later.
> >
> > What about splitting immediately in late-combine? Wouldn't that possibly
> > allow more combinations to immediately happen?
>
> It would be difficult to guarantee termination. Often the split
> instructions can be immediately recombined back to the original
> instruction. Even if we guard against that happening directly,
> it'd be difficult to prove that it can't happen indirectly.
>
> We might also run into issues like PR101523.
>
> Combine uses define_splits (without define_insns) for 3->2 combinations,
> but the current late-combine optimisation is kind-of 1/N+1->1 x N.
>
> Personally, I think we should allow targets to use the .md file to
> define match.pd-style simplification rules involving unspecs, but there
> were objections to that when I last suggested it.
Isn't that what basically "combine-helper" patterns do to some extent?
Richard.
>
> Thanks,
> Richard
