[PATCH 0/5] RISC-V: Zfinx fixes/enhancements: Part 1

[Tsukasa OI]

*** PLEASE READ THIS FIRST ***

-   My (Tsukasa OI's) copyright assignment to FSF is complete.  So,
    applying my other patchsets including previous ones should be safe
    now.  However, there are conflicts and considerations.  See
    "Conflicts with other my pending patchsets" below.

-   This part (PATCH 4) contains small but new proposal (relaxing
    fmv.[sdq] requirements).  Note that before merging.




[About this patchset]

This is the first part (Part 1) of my Z[fdq]inx fixes/enhancements.
I have two options for the second half (Part 2 and 3, an important fix
but require major changes) and will be separated to Part 2A and 2B.

-   Part 1 (you are here)
    Relatively minor Zfinx-related fixes.

-   Part 2 (2A and 2B)
    Fixes an issue that GNU Binutils allows to emit/disassemble illegal
    Zdinx/Zqinx instructions.  We have multiple ways to fix this issue
    but all of them have drawbacks.  So, this part is going to be RFC
    PATCH (mutually exclusive Part 2A and 2B).

-   Part 3
    Test cases for Part 2 (common).  This test is independent from how
    we fix the issue and separated to Part 3.




[Conflicts with other my pending patchsets]

This patchset **conflicts** with my Zfh/Zfhmin patchset (RFC PATCH) as
it lacks new instruction flags I added in Part 2B.

<https://sourceware.org/pipermail/binutils/2022-January/119276.html>

This patchset is a superset of following patchset (included in Part 2),
so after this patchset is merged, fcvt fix patch below is
no longer required (may be merged before this patchset, though):

<https://sourceware.org/pipermail/binutils/2022-January/119239.html>

This patchset is compatible (should not conflict) with patchsets below:

<https://sourceware.org/pipermail/binutils/2022-January/119270.html>
<https://sourceware.org/pipermail/binutils/2022-January/119282.html>
<https://sourceware.org/pipermail/binutils/2022-January/119545.html>




[Patches in Part 1]

DESIGN CHOICE (may be debatable):

1.  Relax `fmv.[sdq]' instruction requirements (PATCH 4).

BUG FIXES:

1.  Disassembling Zfinx/Zdinx/Zqinx instruction with -M numeric does not
    make "floating point" registers numeric.
    [Fixed in PATCH 1]
2.  Zqinx testcases use (possibly) invalid odd-numbered registers
    [Fixed in PATCH 5]

OTHER EDITORIAL CHANGES (in PATCH 2 and 3)...




[PATCH 1: Fix disassembling Zfinx instructions with -M numeric]

The problem is simple.  If you disassemble a Zfinx instruction
`feq.s a0,a1,a2', we get something like this:

80000028 <_start>:
80000028:	a0c5a553          	feq.s	x10,a1,a2

Note that integer operand (a0) is replaced with numeric representaion
(x10) but two floating operands (a1 and a2) are not.

This commit substitutes "replaced FP-GPRs" from ABI names to dynamically
set names (set according to -M numeric option).  After this commit,
we get something like this:

80000028 <_start>:
80000028:	a0c5a553          	feq.s	x10,x11,x12




[PATCH 2 and 3: Editorial changes]

PATCH 2 makes indentation on testcases consistent (by replacing two
spaces with a tab).

PATCH 3 replaces "a0,a0" with "a0,a1" whenever possible for better
encoding space checking.




[PATCH 4: Relax fmv.[sdq] requirements]

For simplicity, I will talk about fmv.d (the same almost applies to
others).

Current GNU Binutils handles `fmv.d' as a part `D' extension but NOT
`Zdinx' extension.  On the other hand, `fmv.d' is an alias of `fsgnj.d'
instruction, which is a part of both `D' and `Zdinx' (correct).

If `fmv.d' is just a register move between general purpose registers,
`mv' pseudoinstruction is probably simpler.

However, this is not the end.  Let's think about `fmv.d a0, a2'.
This is effectively equivalent to following instruction on RV64_Zdinx:

    mv      a0, a2

On Zdinx, we handle floating point numbers using general purpose
registers so it seems using `fmv.d' has no point.
However, this is different on RV32_Zdinx:

    (Execute two instructions atomically)
    mv      a0, a2
    mv      a1, a3

Yes, the register pairs (a0:a1 <- a2:a3).  Because of this, defining
`fmv.d' on RV32_Zdinx enables developers reflect their intent (because
intent of `fsgnj.d' is not clear enough at first glance).

I propose to make `fmv.[sdq]' available to Zfinx/Zdinx/Zqinx extensions.




[PATCH 5: Fix Zqinx tests to use even-numbered registers]

As I later explain in the Part 2A, RV64_Zqinx would require
even-numbered registers (uses register pairs).  This is closely related
to Part 2 (which fixes the issue which allows to emit/disassemble
illegal Zdinx/Zqinx instructions) but can be fixed independently.




Tsukasa OI (5):
  RISC-V: Fix disassembling Zfinx with -M numeric
  RISC-V: Make indentation consistent
  RISC-V: Use different registers for testing
  RISC-V: Relax `fmv.[sdq]' requirements
  RISC-V: Fix RV64_Zqinx to use register pairs

 gas/testsuite/gas/riscv/zdinx.d             |  7 ++-
 gas/testsuite/gas/riscv/zdinx.s             |  7 ++-
 gas/testsuite/gas/riscv/zfinx-dis-numeric.d | 10 +++
 gas/testsuite/gas/riscv/zfinx-dis-numeric.s |  2 +
 gas/testsuite/gas/riscv/zfinx.d             |  7 ++-
 gas/testsuite/gas/riscv/zfinx.s             |  7 ++-
 gas/testsuite/gas/riscv/zqinx.d             | 69 +++++++++++----------
 gas/testsuite/gas/riscv/zqinx.s             | 69 +++++++++++----------
 opcodes/riscv-dis.c                         |  2 +-
 opcodes/riscv-opc.c                         |  6 +-
 10 files changed, 102 insertions(+), 84 deletions(-)
 create mode 100644 gas/testsuite/gas/riscv/zfinx-dis-numeric.d
 create mode 100644 gas/testsuite/gas/riscv/zfinx-dis-numeric.s


base-commit: e327c35ef5768789d3ba41a629f178f5eec32790
-- 
2.32.0