Add a bitwise-or form of NaN propagation.

[sunfishcode]

I recently read about a CPU which has NaN propagation behavior that is not supported by WebAssembly.

This PR proposes to augment WebAssembly's NaN rules to say that when there are multiple NaN inputs, the return can be computed by bitwise-or'ing them together. This change:

• requires no changes in existing implementations
• is basically compatible with the NaN-boxing-on-wasm scheme the current NaN rules aim to support
• keeps nondeterminism quite limited while still supporting current and anticipated hardware designs

That said, the NaN rules are already fairly complex, and this would make them even more so, and it does slightly increase nondeterminism. Dropping the goal of supporting NaN boxing on top of wasm, and/or accepting greater nondeterminism in NaN bits, could simplify the spec in this area.

[kripken]

What's the cpu?

[sunfishcode]

It's an obscure CPU; I think the argument in favor is primarily one of theoretical portability combined with the relatively low impact on everyone else. If an actual CPU does this, others in the future might too.

[gahaas]

I think we should stick to the IEEE-754 standard which says that "the result shall be a quiet NaN which should be one of the input NaNs". It seems to me that this obscure CPU and all future CPUs which behave similar do not satisfy the IEEE-754 standard.

[sunfishcode]

Note the "should" in that sentence; returning a quiet NaN is required, but returning one of the input NaNs is not. RISC-V, and ARM in "default NaN" mode, are examples of CPUs that don't implement the "should" part. Since IEEE itself doesn't require it, and there exists hardware that found some practucal motivation to omit it, future CPUs might omit it too, so it's risky for WebAssembly to require it.

And in practice, the utility of forwarding NaN payloads through arithmetic for diagnostic information purposes, IEEE's stated motivation for this recommendation, is limited, given that WebAssembly can't practically define any actual diagnostics.

WebAssenbly was changed to allow "default NaN behavior" here. This PR currently proposes to further allow bitwise-or behavior too.

[kripken]

Sounds good to me.

[titzer]

@sunfishcode According to the above logic, then this obscure CPU is also IEEE-compliant? If that's the case, then why don't we just adopt the IEEE 754 language? FWIW this NaN behavior doesn't really preclude NaN-boxing as far as I can tell, it just means that implementations need to be able to get the original source inputs rather than relying on the output being a copy of one of the inputs.

[sunfishcode]

@titzer The IEEE 754 language doesn't support the basic NaN boxing use case efficiently, as it would requiring extra canonicalization after arithmetic operations.

Because I recognize this PR adds complexity, I've now also created #716 which proposes an alternative solution, following the "accepting greater nondeterminism in NaN bits" approach suggested above. At most one of these two PRs should be merged.

[flagxor]

Let's do #716 instead.
Closing.