Encoding of signaling/quiet bit in a NaN value

[ibogosavljevic]

Hello!

We are supporting MIPS platform to implement WebAssembly on v8. Signaling/quiet bit in NaN on MIPS architecture is opposite of the same bit on ARM/x64: on MIPS it is zero for quiet NaN whereas it is zero for signaling NaN on other configurations.

I couldn't find in the specs: does WebAssembly specification mandates that quiet NaN has a specific bit in the signaling/quit bit or the architectures are allowed to implement this as it suits them the most?

[sunfishcode]

WebAssembly does require that signaling NaN be encoded with a zero, following the IEEE 754-2008 recommendation and all other relevant architectures. See the floating point operators, where it says "1 in the most significant bit of the fraction field" in NaNs returned by arithmetic instructions.

MIPS has defined an FCSR flag, NAN2008, which changes it to use zero for signaling NaN, allowing platforms supporting this flag to conform to this rule without any other changes.

[ibogosavljevic]

Hi sunfishcode!

Thank you for your prompt reply. NAN2008 in FCSR flag is introduced in R6 flavor of the architecture. There are no R6 chips on the market currently, R2 and R1 are the chips that are massively used and they do not support NAN2008.

Having to support this kind of NaN on R2 and R1 would introduce too much overhead and it's not worth the effort

[gahaas]

What is the reason why we cannot have the signalling bit being non-deterministic, similar to the sign bit. This would not only allow better support for MIPS but also allow to do constant folding on floats.

[rossberg]

I suppose that would imply having 4 canonical NaNs, but that seems fine.

[sunfishcode]

According to the MIPS Architecture For Programmers, NAN2008 is optional in release 3.5 and required in release 5. Is this incorrect?

WebAssembly's current rules already do support constant folding of floats.

The rationale for the quiet bit being deterministic is that it's in preparation for the possibility of adding full IEEE 754-2008 support in WebAssembly. If we don't define the encoding of the quiet bit, producers would have no way of indicating whether they intend signaling or quiet NaNs in their f32.const, f64.const, and data section data, unless we add new abstraction layers, which would entail a fair amount of complexity.

A related issue is WebAssembly's support for NaN boxing. Besides having a different interpretation of the quiet bit, the "MIPS legacy FPU" (as MIPS' documentation calls it) generates qNaNs with all the rest of the fraction field set to ones, while WebAssembly currently requires all zeros. Relaxing the NaN rules to support this would significantly complicate, if not outright exclude, the NaN-boxing use case.

[ibogosavljevic]

NAN2008 is optional in release 3.5 and required in release 5: this is true. Currently > 99% of the deployed chips are release 1 or release 2, and there is a very small number of release 5 cores.

[pizlonator]

I don't think we should optimize WebAssembly for MIPS if it means hurting platforms that people use.

[ibogosavljevic]

@flagxor @gahaas @sunfishcode : I am seeing the discussion here, but no definitive conclusion. We would like to close this topic on v8: if WebAssembly specification requires specific encoding of the signaling/quiet NaN and we cannot support this on releases < 3.5, we will simply not be 100% compatible with WASM.
On the other hand, if it does not require specific encoding of signaling/quiet NaN, we will modify the tests to support the new behavior.

[jfbastien]

@ibogosavljevic :

we cannot support this on releases < 3.5

It seems possible to support MIPS' alternate encoding and be 100% compatible with WebAssembly's current specification. Are you saying it's too expensive to support? NaNs propagate, maybe I'm naive but it seems to me that you can speculate there won't be NaNs in the main path of the code, check propagated values, and fix them up if you mis-speculated.

[titzer]

In offline discussion a clear preference for the current spec has been expressed.

[jfbastien]

Given @titzer's comment, and that this issue was V8-specific, I think this is resolved.