Failing derived floating-point configurations

[davidharrishmc]

The following derived floating-point configurations are not yet passing regression-nightly:

vsim -c -do "do wally-batch.do fh_rv64gc arch64zfh"
hangs on "rv64i_m/Zfh/src/fcvt.h.l_b25-01.S",

f_rv32gc_arch32f
fh_rv32gc_arch32f
f_rv64gc_arch64f
f_rv64gc_arch64f
all fail on fmul_b6 sim = 0, signature = 3
(Kevin Kim looking for root cause)

rv64gc_arch64zfad: fcvtmod.w.d not yet working (Jordan Carlin troubleshooting)
fround/froundx not yet implemented (Jessica Liu and Jordan Carlin writing)

[jordancarlin]

fcvtmod.w.d fixed with #674. Issue still remains with Sail for b22 test.

[davidharrishmc]

vsim -c -do "do wally-batch.do fh_rv64gc arch64zfh" hangs because arch64zfh fcvt.h.l test program performs a fsd, which is not supported in fh. Consider modifying riscv-arch-test so that fcvtmod instructions that don't depend on d don't use it.

riscv-non-isa/riscv-arch-test#367

In the short term, commenting out the fcvt.h.l test cases in tests.vh.

[davidharrishmc]

fcvt.h.l is fixed with corrected macro. Temporarily incorporated into wally-riscv-arch-test.
riscv-non-isa/riscv-arch-test#367

[jordancarlin]

fcvtmod.w.d Sail issue with b22 tests resolved in riscv/sail-riscv/pull/442. Waiting on merge to update riscv-arch-test signature.

[davidharrishmc]

Notes from Jordan about fmul failures:
https://docs.google.com/document/d/1p7zb4Vvd1LMBLRgEpXjHyp7etCaFaiBVrBZJM8jediE/edit

[davidharrishmc]

Invoke with:
vsim -do "do wally.do f_rv32gc arch32f"

[davidharrishmc]

Found a solution to the fmul failures.

The fmul_b6-01.S fails on result 12. The answer is 0. The inexact and underflow bits should be 1 but are computed to be 0 because of the improper shift. This is a single-precision operation on a datapath with Nf = 23.

The operation is 0bd0d96a x 27458574 = 1.1010000… x 2^–104 x 1.1000101100… x 2^-49 = 10.1000010010 x 2^-153 = 1.010… x 2^-152, with a biased exponent of -25. This result is just slightly too small to be subnormal, so it should round to 0, and set the inexact and underflow flags.

The FMA produces Sm = 0x142485c512c10= 10.10 0001 0010 …and Se = 3e6 = -26, both of which are correct. The LZA produces Scnt = 24, which is either accurate or high by 1. Moreover, during subnormal results, Scnt is supposed to be accurate. Sm is U(Nf+3).(2Nf+1) = U26.47, with 73 bits total. There are 49 nonzero lsbs, meaning there are 24 leading zeros, so Scnt is correct.

NormSumExp = Se – (Scnt + 1 - (Nf + 3)) + Biasout – BIAS = -26 - (24 + 1 - (23 + 3) + 127 - 127 = -25. This is also correct because the product was at least 2.0 and had to be shifted right by 1 and then increment Se.

PreResultSubnorm indicates the result is subnormal. According to the code and manuscript, it is set if -(Nf+2) <= NormSumExp <= 0. In this case, NormSumExp = -25, so PreResultSubnorm = 1, indicating the result should be subnormal. Then the ShiftAmt is Se + Nf + 2 = -26 + 23 + 2 = -1 = 127. The shifter shifts the answer to all 0s and gets the wrong value.

This PreResultSubnorm logic seems incorrect. NormSumExp is -25, which should be too small for subnormal.

In an experiment, I changed the lower bound to -(Nf+1) for PreResultSubnorm. regression-wally -nightly is passing now.
Not entirely satisfied this is correct.

[jordancarlin]

riscv/sail-riscv#442 was merged and Sail should now produce the correct signature.

[davidharrishmc]

Whoo!

…

On Apr 29, 2024, at 11:30 AM, Jordan Carlin ***@***.***> wrote: riscv/sail-riscv#442 <riscv/sail-riscv#442> was merged and Sail should now produce the correct signature. — Reply to this email directly, view it on GitHub <#655 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AR4AA36MQZIZGLJXU7C4PRLY72GUHAVCNFSM6AAAAABEJ75GYOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBTGM4DSOJRGY>. You are receiving this because you authored the thread.

[davidharrishmc]

Closed with PR #794.