[PATCH 05/19] RISC-V: EEW64 checking
Jiawei
jiawei@iscas.ac.cn
Tue Apr 28 03:00:20 GMT 2026
> Like the assembler, the disassembler should also use the INSN_V_EEW64
> flag. Respectively marked insns shouldn't be disassembled normally when
> Zve64x isn't enabled.
>
> While there also drop the redundant Zve32x check from gas: All affected
> insns are INSN_CLASS_V, which means Zve32x was already checked to be
> enabled (both V and Zve64x imply Zve32x).
> ---
> Question is why a flag was used in the first place: The property could be
> expressed by a new INSN_CLASS_ZVE64X, couldn't it?
>
Using INSN_V_EEW64 in the disassembler looks right to me. For these
integer vector load/store instructions, the important distinction is whether
Zve64x is available; otherwise an EEW64 instruction should not be printed as
a normal instruction.
Dropping the explicit Zve32x check in gas also looks reasonable, since these
instructions are already covered by the vector instruction class check, and
the remaining extra requirement is Zve64x.
I think keeping INSN_V_EEW64 is fine here. It describes the EEW-related
property of these vector load/store entries, while the instruction class
still describes the broader vector instruction class. Introducing a
separate INSN_CLASS_ZVE64X would also work, but seems like a larger
table-organization change.
Best regards,
Jiawei
>
> --- a/gas/config/tc-riscv.c
> +++ b/gas/config/tc-riscv.c
> @@ -2944,10 +2944,9 @@ riscv_ip (char *str, struct riscv_cl_ins
> insn_with_csr = false;
> }
>
> - /* The (segmant) load and store with EEW 64 cannot be used
> + /* The (segment) load and store with EEW 64 cannot be used
> when zve32x is enabled. */
> - if (ip->insn_mo->pinfo & INSN_V_EEW64
> - && riscv_subset_supports (&riscv_rps_as, "zve32x")
> + if ((ip->insn_mo->pinfo & INSN_V_EEW64)
> && !riscv_subset_supports (&riscv_rps_as, "zve64x"))
> {
> error.msg = _("illegal opcode for zve32x");
> --- a/opcodes/riscv-dis.c
> +++ b/opcodes/riscv-dis.c
> @@ -1018,10 +1018,16 @@ riscv_disassemble_insn (bfd_vma memaddr,
> && (op->xlen_requirement != pd->xlen))
> continue;
> /* Is this instruction supported by the current architecture? */
> - if (!pd->all_ext
> - && !riscv_multi_subset_supports (&pd->riscv_rps_dis,
> - op->insn_class))
> - continue;
> + if (!pd->all_ext)
> + {
> + if (!riscv_multi_subset_supports (&pd->riscv_rps_dis,
> + op->insn_class))
> + continue;
> +
> + if ((op->pinfo & INSN_V_EEW64)
> + && !riscv_subset_supports (&pd->riscv_rps_dis, "zve64x"))
> + continue;
> + }
>
> /* It's a match. */
> (*info->fprintf_styled_func) (info->stream, dis_style_mnemonic,
> --- /dev/null
> +++ b/gas/testsuite/gas/riscv/eew64.d
> @@ -0,0 +1,13 @@
> +#as: -march=rv32i
> +#objdump: -d
> +
> +.*:[ ]+file format .*
> +
> +Disassembly of section .text:
> +
> +0+000 <eew32>:
> +[ ]+0:[ ]+020ff007[ ]+\.insn[ ]+4, ?0x020ff007
> +
> +0+004 <eew64>:
> +[ ]+4:[ ]+020ff007[ ]+vle64\.v[ ]+v0,\(t6\)
> +#pass
> --- /dev/null
> +++ b/gas/testsuite/gas/riscv/eew64.s
> @@ -0,0 +1,12 @@
> + .option arch, rv32i
> + .option arch, +zve32x
> +
> +eew32:
> + # vle64.v v0, (x31)
> + .insn 4, 0x020ff007
> +
> + .option arch, rv32i
> + .option arch, +zve64x
> +
> +eew64:
> + vle64.v v0, (x31)
>
More information about the Binutils
mailing list