>> + >> +(define_insn "@pred_vfwdota_vv_zvdota<mode>" >> + [(set (match_operand:<ZVFWDOTBF_ACC> 0 "register_operand" >> "=&vr") >> + (if_then_else:<ZVFWDOTBF_ACC> >> + (unspec:<VM> >> + [(match_operand:<VM> 1 "vector_mask_operand" >> "vmWc1") >> + (match_operand 5 "vector_length_operand" " >> rvl") >> + (match_operand 6 "const_int_operand" " >> i") >> + (match_operand 7 "const_int_operand" " >> i") >> + (match_operand 8 "const_int_operand" " >> i") >> + (reg:SI VL_REGNUM) >> + (reg:SI VTYPE_REGNUM)] UNSPEC_VPREDICATE) >> + (unspec:<ZVFWDOTBF_ACC> >> + [(match_operand:ZVFWDOTBF_SRCMODE 3 "register_operand" " >> vr") >> + (match_operand:ZVFWDOTBF_SRCMODE 4 "register_operand" " >> vr") >> + (match_operand:<ZVFWDOTBF_ACC> 2 "register_operand" " >> 0")] >> + UNSPEC_VFWDOTA) >> + (match_dup 2)))] > I haven't looked at this extension closely, but presumably with the > widening nature we have to avoid certain overlaps? Robin is looking at > a better solution for that problem that should give us more flexibility > in the register allocation phase.
I think the earlyclobber is conservatively correct and yes, those would be good candidates for the new dependent constraints. -- Regards Robin
