<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 2026/6/15 16:39, Jan Beulich wrote:<br>
</div>
<blockquote type="cite"
cite="mid:0d0b3cd4-8358-4497-b168-b1409296941b@suse.com">
<pre wrap="" class="moz-quote-pre">On 09.06.2026 17:38, Jiawei wrote:
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">--- /dev/null
+++ b/gas/testsuite/gas/riscv/zvdota.d
@@ -0,0 +1,19 @@
+#as: -march=rv64gc_zvqwdota8i_zvqwdota16i_zvfwdota16bf_zvfqwdota8f
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">
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?
</pre>
</blockquote>
<p><span>Hi Jan,</span></p>
<p>Thanks for the suggestion.<br>
<br>
Yes, I agree. I will add zvdota and zvbdota as roll-up names in
v2:<br>
<br>
<span> zvdota -> zvqwdota8i + zvqwdota16i + zvfwdota16bf +
zvfqwdota8f</span><br>
<span> zvbdota -> zvqwbdota8i + zvqwbdota16i + zvfwbdota16bf</span><br>
<span> + zvfqwbdota8f + zvfbdota32f</span><br>
</p>
<p class="isSelectedEnd"><span>The individual extensions will remain
available, and the instruction</span><br>
<span>entries will continue to be gated by the individual
extension classes.</span><br>
<span>The roll-up names will just imply the corresponding
individual extensions,</span><br>
<span>so existing per-instruction gating does not need to change.</span></p>
<p class="isSelectedEnd"><span>I will also update the tests to use
-march=..._zvdota and</span><br>
<span>-march=..._zvbdota in the main coverage tests, while keeping
small tests</span><br>
<span>for the shared integer encodings where needed.</span></p>
<p><span>I can also</span><span> propose the corresponding
Zvdota/Zvbdota dependency expansions</span></p>
<p><span>in the ISA</span><span> spec, similar to how the RISC-V B
extension is defined in terms of its</span></p>
<p><span>component</span><span> extensions. That way binutils would
not be the only place defining</span></p>
<p><span>these</span><span> aliases.</span></p>
<blockquote type="cite"
cite="mid:0d0b3cd4-8358-4497-b168-b1409296941b@suse.com">
<pre wrap="" class="moz-quote-pre">
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">--- 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},
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">
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</pre>
</blockquote>
<p class="isSelectedEnd"><span>Regarding the .insn OP-VE forms: this
series only adds named opcodes and</span><br>
<span>does not introduce new .insn forms. But I agree that
Zvdota/Zvbdota add</span><br>
<span>more evidence that the future OP-VE .insn syntax should
account for ivv</span><br>
<span>and fvv-style encodings under the 0x77 major opcode as well.</span></p>
<p><span>Thanks,</span><br>
<span>Jiawei</span></p>
<p></p>
</body>
</html>