[RFC 1/2] RISC-V: Add Zvdota extension classes

[Jan Beulich]

On 09.06.2026 17:38, Jiawei wrote:
> --- /dev/null
> +++ b/gas/testsuite/gas/riscv/zvdota.d
> @@ -0,0 +1,19 @@
> +#as: -march=rv64gc_zvqwdota8i_zvqwdota16i_zvfwdota16bf_zvfqwdota8f

As can be seen very "neatly" here, the need to specify effectively every
insn's extension separately (really only one of zvqwdota8i and zvqwdota16i
should be necessary to spell out) is getting unwieldy. The situation is
even worse with what patch 2 adds. Could we consider a shorthand zvdota
here (and zvbdota in patch 2), covering all extensions in one go?

> --- a/opcodes/riscv-opc.c
> +++ b/opcodes/riscv-opc.c
> @@ -2226,6 +2226,13 @@ const struct riscv_opcode riscv_opcodes[] =
>  {"vfwmaccbf16.vf",  0, INSN_CLASS_ZVFBFWMA, "Vd,S,VtVm",  MATCH_VFWMACCBF16_VF, MASK_VFWMACCBF16_VF, match_opcode, 0},
>  {"vfwmaccbf16.vv",  0, INSN_CLASS_ZVFBFWMA, "Vd,Vs,VtVm", MATCH_VFWMACCBF16_VV, MASK_VFWMACCBF16_VV, match_opcode, 0},
>  
> +/* Zvdota instructions.  */
> +{"vqwdotau.vv", 0, INSN_CLASS_ZVQWDOTA8I_OR_ZVQWDOTA16I, "Vd,Vt,VsVm", MATCH_VQWDOTAU_VV, MASK_VQWDOTAU_VV, match_opcode, 0},
> +{"vqwdotas.vv", 0, INSN_CLASS_ZVQWDOTA8I_OR_ZVQWDOTA16I, "Vd,Vt,VsVm", MATCH_VQWDOTAS_VV, MASK_VQWDOTAS_VV, match_opcode, 0},
> +{"vfwdota.vv",  0, INSN_CLASS_ZVFWDOTA16BF, "Vd,Vt,VsVm", MATCH_VFWDOTA_VV, MASK_VFWDOTA_VV, match_opcode, 0},
> +{"vfqwdota.vv", 0, INSN_CLASS_ZVFQWDOTA8F, "Vd,Vt,VsVm", MATCH_VFQWDOTA_VV, MASK_VFQWDOTA_VV, match_opcode, 0},
> +{"vfqwdota.alt.vv", 0, INSN_CLASS_ZVFQWDOTA8F, "Vd,Vt,VsVm", MATCH_VFQWDOTA_ALT_VV, MASK_VFQWDOTA_ALT_VV, match_opcode, 0},

I'm glad I didn't commit my "RISC-V: add dedicated vector arithmetic .insn
forms" yet. Prior to this series only a very limited set of OP-VE encodings
were in use (in mvv iirc). Now ivv and fvv encodings appear as well, hence
I think we want to re-consider what we discussed regarding the RFC that I
continue to have in that patch: It may end up being better then if the
major opcode also needs spelling out in the .insn operands. Then the new
forms here could be encoded that same way, right from the beginning.

For reference, I've locally extended that RFC remark like this:

"RFC: OP-VE reuses (at least) OPMVV, so "mvv" would end up ambiguous if we
      wanted to also introduce insn forms there; with Zvdota and Zvbdota
      "ivv" and "fvv" also become used under that same major opcode. Otoh
      I wanted to avoid having O7 as the first operand everywhere. An
      option might be to distinguish future OP-VE ones (in the once
      supposed P extension encoding space iirc) by e.g. prefixing with P,
      or - derived from OP-VE - with E. Yet that would likely end up being
      a fully redundant set in the long run."

It is really unfortunate that none of the RISC-V maintainers has voiced
any opinion so far ...

Jan