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

[Jiawei]

On 2026/6/15 16:39, Jan Beulich wrote:
> 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?

Hi Jan,

Thanks for the suggestion.

Yes, I agree. I will add zvdota and zvbdota as roll-up names in v2:

zvdota -> zvqwdota8i + zvqwdota16i + zvfwdota16bf + zvfqwdota8f
zvbdota -> zvqwbdota8i + zvqwbdota16i + zvfwbdota16bf
+ zvfqwbdota8f + zvfbdota32f

The individual extensions will remain available, and the instruction
entries will continue to be gated by the individual extension classes.
The roll-up names will just imply the corresponding individual extensions,
so existing per-instruction gating does not need to change.

I will also update the tests to use -march=..._zvdota and
-march=..._zvbdota in the main coverage tests, while keeping small tests
for the shared integer encodings where needed.

I can also propose the corresponding Zvdota/Zvbdota dependency expansions

in the ISA spec, similar to how the RISC-V B extension is defined in 
terms of its

component extensions. That way binutils would not be the only place defining

these aliases.

>> --- 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

Regarding the .insn OP-VE forms: this series only adds named opcodes and
does not introduce new .insn forms. But I agree that Zvdota/Zvbdota add
more evidence that the future OP-VE .insn syntax should account for ivv
and fvv-style encodings under the 0x77 major opcode as well.

Thanks,
Jiawei
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/binutils/attachments/20260616/ca4dc482/attachment.htm>