[RISC-V] NaN propagation should occur where feasible

[tannergooding]

Summary

The IEEE 754 specification recommends, but does not require, that operations propagate the input back as the output if it is a NaN, or one of the NaNs if the operation supports multiple.

This is something that most hardware follows and that a large amount of software depends on, particularly as it pertains to certain web scenarios where "NaN boxing" is fairly prevalent. For example, this is utilized by WebKit and called out by the WASM specs. It is also extensively used by SIMD algorithms due to the floating-point and integral SIMD registers being one and the same, so it is typical to produce some Vector128<float> that is AllBitsSet (a qNaN with a full payload) and then use that in a subsequent instruction.

.NET has correspondingly done NaN propagation historically and made efforts to ensure this operates as expected for users in the face of constant folding and other scenarios.

Issue

RISC-V differs in that they explicitly chose to not propagate and to always normalize, outside of a few operations that are strictly documented to operate on raw-bits. While this is "technically allowed", it creates a division in customer expectations for .NET and is likely to break real world apps.

This came up, for example, in #118589 when looking at the logic generated for the Min/Max APIs, since they just returned "some NaN".

The RISC-V codegen should ideally be updated to follow the same practices as our other hardware so that apps and user expectations are not subtly broken when running on such hardware. This will represent a perf penalty in some cases, but we correspondingly have APIs such as MinNative/MaxNative which are allowed to differ on such edges for places where it is irrelevant but the performance is necessary.

Fixing this is inline with other cross-platform determinism fixes we've done over past releases, including such as ensuring (int)someFloat saturates on overflow, which included minor perf hits to platforms that are currently more common for users to have.

[dotnet-policy-service]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

[tomeksowi]

I think it should be better specified which APIs/operations are required to propagate NaN sign and payload and which are fine with what IEEE 754 requires.

In most cases it will require adding a check for NaN for each argument and a branch or two. I don't see a way to do it branchless like #94762, treating FP as integer requires an explicit fmv.x.[wd] and then another fmv to put it back in a FP register. For vector operations (not supported yet on RISC-V) branchless may be easier since they all happen in the same register bank v0-v31 and masking is supported.

I don't see a problem conforming to additional requirements if necessary, I'm just concerned about the cost.

[tannergooding]

I agree that trying to handle NaN propagation "everywhere" would be problematic and would likely make simple floating-point arithmetic mostly "unusable" on RISC-V (which makes it all the more unfortunate that RISC-V decided to deviate here).

I also expect that "computation" operations are less likely to be problematic. So I would classify operations such as +, - (binary), *, /, sqrt, etc as being "fine" to not strictly propagate back the input NaN (although if there are instructions or features that guarantee this, then it would be preferred to propagate).

I would instead say that any trivial "bitwise" operation (abs, - (unary), etc) or function which is functionally performing a comparison and claiming to return one of the values (min, max, minNum, maxNum, etc) must propagate, as they are stating that they do not compute a new value and/or are stated by IEEE 754 to explicitly operate on NaNs in a particular way. -- Which, yes, technically even with the explicit documentation on behavior, they can still be considered optional based on the latter parts of the spec stating that no NaN propagation is actually required. But rather by virtue of them having that explicit statement on behavior for NaNs and being functionally bitwise or comparisons, are expected to behave as such without normalizing.

[tannergooding]

I wouldn't expect any additional cost to doing this for operations like abs or - (unary) are they are largely bitwise operations already. There may be some additional cost for comparison like functions such as min, but that should be fine as we have MinNative and MaxNative for if users want perf and don't care about such edges.

[tomeksowi]

Yes, abs, negate, copy, copy sign, as well as bit transfers between FP and integer are required by IEEE 754 to handle NaN transparently, RISC-V respects that.

Which leaves us with min/max.

For min/max, min/maxNum if both arguments are NaN, AFAIK native instructions for most architectures (at least arm64, LoongArch, s390x, RISC-V) return a canonical NaN, x64 is the odd one out preserving the payload of the second argument. Matching x64 seems forced here. Do .NET implementations of Min/MaxNumber add instructions to match x64 behavior or just issue native instructions?

So min/max (non-number) with one NaN argument seems the only one really worth considering, especially that it has the *Native versions with relaxed requirements as you mentioned. What are the real-life benefits of preserving payload of the only NaN argument in Min/Max? Any computing techniques that rely on it?

[tannergooding]

AFAIK native instructions for most architectures (at least arm64, LoongArch, s390x, RISC-V) return a canonical NaN

Arm64 depends on FPCR.DN (default NaN) and FCPR.AH (alternative handling):

• When FPCR.AH is 0, the behavior is as follows:
  • Negative zero compares less than positive zero.
  • When FPCR.DN is 0, if either value is a NaN, the result is a quiet NaN.
  • When FPCR.DN is 1, if either value is a NaN, the result is Default NaN.
• When FPCR.AH is 1, the behavior is as follows:
  • If both values are zeros, regardless of the sign of either zero, the result is the second value.
  • If either value is a NaN, regardless of the value of FPCR.DN, the result is the second value.

That is, FPCR.AH == 1 controls historical x64 compatibility, while FPCR.DN controls canonicalization. The "quiet NaN" result is just stripping the signal bit, as is standard, to stop further propagation of the signal (and can be seen if you follow through the documented FPProcessNaNs implementation).

.NET requires AH=0 and DN=0, we don't allow freely changing the state of the floating-point control registers from what we initialize it to at startup. Having it modified in the context of the JIT, GC, or managed code running is undefined behavior.

x64 is the odd one out preserving the payload of the second argument

This is a bit nuanced as well. The minss/maxss instructions behave this way but are known to not be IEEE 754 compliant. We explicitly add additional logic to ensure it is handled correctly and use a selection of comparisons and blending operations to ensure -0 vs +0 and NaN are correctly handled. On newer AVX512 capable hardware we have the rangess instruction and that allows a better range of handling, but is still not fully IEEE 754 compliant. We continue doing a selection of comparisons and blending to ensure NaN is correctly handled. AVX10 then introduces IEEE 754 compliant handling and we are back to a single instruction.

What are the real-life benefits of preserving payload of the only NaN argument in Min/Max

It ensures that error propagation, boxed NaNs, or other common scenarios where NaNs are intentionally used are correctly preserved. These often end up in comparison or other APIs where the result is explicitly not expected to be mutated. It also helps avoid accidental breaks across platforms, which users are hitting as they try to support more implicitly.

We were willing to pay the minor additional cost on the majority platform to achieve this determinism, so we're ok with that cost on the newer platforms that aren't currently seeing as widespread of usage. I expect that this will also ease overall adoption long term.

[tomeksowi]

We were willing to pay the minor additional cost on the majority platform to achieve this determinism, so we're ok with that cost on the newer platforms that aren't currently seeing as widespread of usage. I expect that this will also ease overall adoption long term.

Sounds good to me.

Now to sum up, what's the desired determinism of .NET APIs on top of IEEE 754?

• Min/Max with one NaN argument -- return the NaN argument verbatim with same sign and payload, or quiet canonical NaN to match arm64?
• Min/MaxNumber, Min/Max with both NaN arguments -- quiet canonical NaN?