At 2026/6/16 3:13, Robin Dapp wrote:
+
+(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.
Hi Robin,
Thanks for confirming. I will keep the current earlyclobber constraints
for this RFC since they are conservative and do not depend on the new
constraint machinery. I will also add these patterns to the list of
candidates to revisit once the dependent-constraint work is available.
Thanks,
Jiawei
