[PATCH 10/19] RISC-V: check operands for Zdinx in RV32

[Jan Beulich]

On 28.04.2026 10:45, Jiawei wrote:
>> Like for Zilsd, register pair operands are required to be encoded with the
>> low bit clear. Since match functions don't have XLEN available, introduce
>> respective flags, to be used explicitly in assembler and disassembler.
>> ---
>> What about Zqinx? There's no formal spec for that extension afaics. For
>> RV64, does that behave like Zdinx for RV32? For RV32, does it require
>> register numbers to be divisible by 4? Or is it not a thing there in the
>> first place?
>>
>> No similar checking is easily possible for scalar vector insns, as element
>> width there isn't encoded in the insn. (Plus V and Zdinx can't be enabled
>> together right now anyway.)
>>
>> We could further use RV32_EVEN_CHECK for Zilsd as well, then allowing to
>> eliminate one or two match functions. (Hence RV32_EVEN_CHECK()'s scope is
>> pretty wide.)
>>
> The RV32 Zdinx operand checking looks right to me. In RV32, double-precision
> values in GPRs need to be represented as register pairs, so the corresponding
> D/S/T/R operands must use even-numbered registers.
> 
> The new INSN_RV32_EVEN_* flags look like a good way to express this
> requirement in the opcode table, and it is useful that both the assembler and
> disassembler check the same property. The gating on xlen == 32 and
> RCLASS_GPR also avoids affecting the normal FPR-based D extension case.
> 
> Regarding Zqinx, I found that the old binutils Zqinx register tests treated
> RV64 Zqinx as using register pairs, and RV32 Zqinx as using register pairs
> and quad-register groups.
> 
> https://sourceware.org/pipermail/binutils/2022-February/119683.html
> 
> So the natural rule would be that RV64 Zqinx needs
> even-numbered registers for Q operands, while RV32 Zqinx needs registers
> divisible by 4 for Q operands. However, the Zfinx specification also says
> that Zqinx is not considered further in that document, so I agree it is better
> not to infer or add Zqinx checking in this patch.

Certainly not in this patch, but something wants doing there. Right now it is
as broken as Zdinx in RV32. The question hence isn't _whether_ to do something,
but _what_ to do. For which it would help if there was at least some informal
spec somewhere.

I wonder why the patch you reference (and really the entire series) was (afaics)
never committed.

Jan