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.
Thanks,
Richard
