On 6/11/2026 1:54 AM, Jiawei wrote:
Add RTL patterns for the Zvdota and Zvbdota dot-product
instructions. The patterns model the destructive accumulator operand
and use explicit altfmt operands where the runtime vtype.altfmt state
selects the VS1 interpretation. Zvbdota patterns also take a scaled
ci immediate operand.
gcc/ChangeLog:
* config/riscv/predicates.md (zvbdota_ci_operand): New operand.
* config/riscv/riscv-protos.h (enum mask_policy): Update altfmt
comment.
* config/riscv/riscv.md: Include vector-dot.md.
* config/riscv/vector-iterators.md: Add UNSPEC and iterator
definitions for Zvdota and Zvbdota.
* config/riscv/vector-dot.md: New file.
---
gcc/config/riscv/predicates.md | 5 +
gcc/config/riscv/riscv-protos.h | 5 +-
gcc/config/riscv/riscv.md | 1 +
gcc/config/riscv/vector-dot.md | 246 +++++++++++++++++++++++++++
gcc/config/riscv/vector-iterators.md | 207 ++++++++++++++++++++++
5 files changed, 461 insertions(+), 3 deletions(-)
create mode 100644 gcc/config/riscv/vector-dot.md
diff --git a/gcc/config/riscv/riscv-protos.h b/gcc/config/riscv/riscv-protos.h
index fa360157570..a8a40f5dda9 100644
--- a/gcc/config/riscv/riscv-protos.h
+++ b/gcc/config/riscv/riscv-protos.h
@@ -663,9 +663,8 @@ enum mask_policy
/* Values for the VTYPE altfmt field. Instructions that do not care about
altfmt leave the "altfmt" insn attribute at its default
(INVALID_ATTRIBUTE);
- FP8 instructions select between standard (ALTFMT_NONE, E4M3) and the
- alternate format (ALTFMT_ALT, E5M2) by setting the attribute via an
- operand. */
+ Some dot-product instructions select their vs1 interpretation by setting
+ the attribute via an operand. */
Why drop the FP8 parts of this comment?
+
+(define_insn "@pred_<zvqwdot>_vv_zvdota<mode>"
+ [(set (match_operand:<ZVQWDOTI_ACC> 0 "register_operand" "=&vr")
+ (if_then_else:<ZVQWDOTI_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:<ZVQWDOTI_ACC>
+ [(match_operand:ZVQWDOTI_SRCMODE 3 "register_operand" "
vr")
+ (match_operand:ZVQWDOTI_SRCMODE 4 "register_operand" "
vr")
+ (match_operand:<ZVQWDOTI_ACC> 2 "register_operand" "
0")
+ (match_operand 9 "const_int_operand" "
i")]
+ ZVQWDOT)
+ (match_dup 2)))]
+ "TARGET_VECTOR"
Don't we need a stronger condition here? These are only available when
the SDOT extensions are enabled, so we should be testing for that.
Similarly for other new patterns/expanders.
+
+(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.
GIven all the new iterators, I'd like Robin to take a looksie as well.
I forgot to ask, have these extensions reached a frozen state yet?
Jeff
