Skip to content

cmd/internal/obj/riscv: use FLIS/FLID for float constants on rva23u64 - #82359

Draft
lxq015 wants to merge 13 commits into
golang:masterfrom
lxq015:zfa_compiler
Draft

lxq015 wants to merge 13 commits into
golang:masterfrom
lxq015:zfa_compiler

Conversation

@lxq015

@lxq015 lxq015 commented Oct 20, 2026 •

Copy link
Copy Markdown
Contributor

On rva23u64, use the Zfa FLIS/FLID instructions to materialize float
constants from the Zfa immediate table instead of loading them from
memory.

Updates #732700

lxq015 added 12 commits October 10, 2026 09:31
…ouble

The single fimmMapping keyed by float64 served both FLIS (single-precision
immediate) and FLID (double-precision immediate), which made progedit and
the encoder disagree: progedit looked up float64(f32) (the operand rounded
to float32 then widened back) while the encoder looked up the original
float64 operand. A double like 1.0000000000000002 rounds to 1.0 as float32
and would pass progedit's check but fail the encoder's, producing an
"unknown floating point immediate" error.

Split the map into flisMapping (float32 keys) and flidMapping (float64
keys), and check each instruction in its own domain: FLIS keys on the
float32 value, FLID on the float64 value. Also check NaN on float32
directly (f32 != f32) since math.IsNaN only accepts float64.
flidMapping[1] was copied from flisMapping and held the single-precision
minimum positive normal (2^-126, 1.1754943508222875e-38). Per the RISC-V
Zfa spec, entry 1 (the minimum positive normal value) has a numerically
different value for double-precision, so flidMapping[1] must be the
double-precision minimum positive normal 2^-1022
(2.2250738585072014e-308).

Update the corresponding FLID test line in riscv64.s to use the double
value; its encoding (index 1) is unchanged.
The Zfa fround/froundnx instructions take an explicit rounding mode in the
rm field (bits 14:12), but AFROUNDS/AFROUNDNXS/AFROUNDD/AFROUNDNXD were
only given rFFEncoding, which hardcoded funct3 to 0 (RNE) with no way to
select another rounding mode.

Wire them into the existing rounding-mode suffix mechanism used by fcvt:
ParseSuffix now accepts .RNE/.RTZ/.RDN/.RUP/.RMM on the fround instructions
and stores the mode in Scond, and instructionsForProg writes it into
funct3, defaulting to RNE when no suffix is given (preserving the previous
encoding for suffix-free fround).

Add end-to-end tests for all four fround instructions across all five
rounding modes.
@lxq015
lxq015 marked this pull request as draft October 20, 2026 07:18
@gopherbot

Copy link
Copy Markdown
Contributor

This PR (HEAD: 48307c9) has been imported to Gerrit for code review.

Please visit Gerrit at https://go-review.googlesource.com/c/go/+/851245.

Important tips:

  • Don't comment on this PR. All discussion takes place in Gerrit.
  • You need a Gmail or other Google account to log in to Gerrit.
  • To change your code in response to feedback:
    • Push a new commit to the branch used by your GitHub PR.
    • A new "patch set" will then appear in Gerrit.
    • Respond to each comment by marking as Done in Gerrit if implemented as suggested. You can alternatively write a reply.
    • Critical: you must click the blue Reply button near the top to publish your Gerrit responses.
    • Multiple commits in the PR will be squashed by GerritBot.
  • The title and description of the GitHub PR are used to construct the final commit message.
    • Edit these as needed via the GitHub web interface (not via Gerrit or git).
    • You should word wrap the PR description at ~76 characters unless you need longer lines (e.g., for tables or URLs).
  • See the Sending a change via GitHub and Reviews sections of the Contribution Guide as well as the FAQ for details.

@gopherbot

Copy link
Copy Markdown
Contributor

This PR (HEAD: 5efa00b) has been imported to Gerrit for code review.

Please visit Gerrit at https://go-review.googlesource.com/c/go/+/851245.

Important tips:

  • Don't comment on this PR. All discussion takes place in Gerrit.
  • You need a Gmail or other Google account to log in to Gerrit.
  • To change your code in response to feedback:
    • Push a new commit to the branch used by your GitHub PR.
    • A new "patch set" will then appear in Gerrit.
    • Respond to each comment by marking as Done in Gerrit if implemented as suggested. You can alternatively write a reply.
    • Critical: you must click the blue Reply button near the top to publish your Gerrit responses.
    • Multiple commits in the PR will be squashed by GerritBot.
  • The title and description of the GitHub PR are used to construct the final commit message.
    • Edit these as needed via the GitHub web interface (not via Gerrit or git).
    • You should word wrap the PR description at ~76 characters unless you need longer lines (e.g., for tables or URLs).
  • See the Sending a change via GitHub and Reviews sections of the Contribution Guide as well as the FAQ for details.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants