riscv_float_combined

Combined floating point enhancements

• Status: WITHDRAWN (Splitted)
  • RISC-V: Zfinx-related fixes (1)
  • An ongoing patchset
• Branch: riscv-float-combined
• Tracking PR: #7 (view Pull Request and Diff)
• Mailing List:
  • PATCH v1 (2022-06-02)
  • PATCH v2 (2022-06-27)
  • PATCH v3 (2022-07-10)
  • PATCH v4 (2022-07-24)
  • PATCH v5 (2022-09-04)

Conflicts With

• Upcoming (Pending): Disassembler: Support special (non-standard) encodings
  It also touches floating point instructions.
• Pending (RFC): Disassembler: Check shift amount against XLEN (Idea 1)
  This patch doesn't implement instruction matching functions newly declared in this patchset.

A. Issues Solved with this Patch Set

A.1. Enhance Zfinx/Zdinx/Zqinx Testcases (v5: PATCH 1/3)

I enhanced Zfinx/Zdinx/Zqinx testcases based on Jiawei's Zhinx support patch. I also...

• Made indentation / coding style consistent and clean
• Started to use valid register number (on Zqinx)
• Started to use different register per operand

A.2. Relax Requirements to fmv.[sdq] instructions (v5: PATCH 2/3)

On Zfinx/Zdinx/Zqinx, fmv instructions seem redundant but actually not. On RV32_Z[dq]inx and RV64_Zqinx, it requires register pair. That means, single...

fmv.d  x10, x12

is equivalent to 2 regular instructions on RV32_Zdinx (with 32-bit GPRs):

mv  x10, x12
mv  x11, x13

Since fsgnj.[sdq] (base instruction of fmv.[sdq]) are a part of Z[fdq]inx extensions, it's safe to implement this pseudo-instructions.

This patch makes fmv.[sdq] available to Zfinx/Zdinx/Zqinx environments.

A.3. Validate Register pairs on Zdinx/Zqinx (v5: PATCH 3/3)

On RV32_Zdinx and RV64_Zqinx, all registers holding a FP64 value must be even (x0, x2, x4... are valid, x1, x3, x5... are invalid). On RV32_Zqinx, it would be that all registers holding a FP128 value will be required to have a multiple of 4 (x0, x4, x8... are valid, x1, x2, x3, x5... are not).

On RV32_Zdinx, this is valid.

fadd.d  x10, x12, x14

On the other hand, this is not valid (invalid on RV32_Zdinx, valid on RV64_Zdinx).

fadd.d  x11, x13, x15

Current Binutils can generate invalid instructions with odd register numbers (or register number x % 4 != 0). First half of the changes makes those invalid.

Testcases (second half) are separate only because it is quite large.

B. Issues Solved (Merged)

B.1. Canonical Ordering of H

• Status: Merged for 2.39
• PATCH v1: PATCH 1/9

For canonical ordering of Zhinx extension (and future Zhinxmin extension), it requires determining canonical order of H. I raised an issue and made a consensus that H will be placed after V. Considering current software compatibility, P, V, N then H ordering is good for toolchain.

On GNU Binutils, this requires adding h character to riscv_ext_canonical_order in bfd/elfxx.c.

This patch is independently applied to master and removed in PATCH v2.

B.2. Extension Support: Zfhmin and Zhinxmin

• Status: Merged for 2.39
• PATCH v1: PATCH 4/9
• PATCH v2: PATCH 3/8

This patch implements Zfhmin and Zhinxmin extensions, conversion-only subsets of Zfh/Zhinx instruction set extensions, respectively.

As this patch is merged for 2.39 (with intense porting by Nelson Chu), this is removed on PATCH v3.

B.3. Disassembler output with Zfinx + -M numeric option

• Status: Merged for 2.39
• PATCH v1: PATCH 5/9
• PATCH v2: PATCH 4/8

Disassembling Zhinx/Zhinxmin/Zfinx/Zdinx/Zqinx instructions with -M numeric option has an issue. It used ABI names instead of numeric one. This patch fixes that.

As this patch is merged for 2.39 (with intense porting by Nelson Chu), this is removed on PATCH v3.

C. Postponed Changes

C.1. MINOR: Refactoring / Better consistency with other instructions

C.1.1. Refactoring for better integration with F/D/Q

• Status: Postponed for Another Patchset
• PATCH v1: PATCH 2/9
• PATCH v2: PATCH 1/8

C.1.2. Add DECLARE_INSN declarations

• Status: Postponed for Another Patchset
• PATCH v1: PATCH 3/9
• PATCH v2: PATCH 2/8