@dotnet/jit-contrib PTAL

Tagging subscribers to 'arch-wasm': @lewing, @pavelsavara
See info in area-owners.md if you want to be subscribed.

I think you'd want @tannergooding's review. These intrinsics are tricky around IEEE754.

E.g. it seems f32.max in WASM corresponds to IEEE 754-2019's maximum. Is it the same for Math.Max? Same concerns for min, round

The Wasm spec says:

NaN Propagation

When the result of a floating-point operator other than fneg, fabs, or fcopysign is a NaN, then its sign is non-deterministic and the payload is computed as follows:
• If the payload of all NaN inputs to the operator is canonical (including the case that there are no NaN inputs), then the payload of the output is canonical as well.
• Otherwise the payload is picked non-deterministically among all arithmetic NaNs; that is, its most significant bit is 1 and all others are unspecified.

If we must explicitly check for and propagate NaN inputs this may tip the scale in favor of always using a helper call (especially for binops).

Notably, the NaN propagation issue affects all FP operations, not just intrinsics. What are our actual semantic requirements for it (required for all ops, required only for min/max, required for all Math)?

I will note that from glancing at the interpreter code, it uses native floating point operations in C++ and doesn't take any steps to preserve NaNs. I ran a snippet of the interpreter through godbolt and it doesn't look like clang generated any special wasm to preserve NaNs for those operations either (I looked at add and mul).

So for consistency with the interpreter as it currently exists, we'd want to use the native opcodes in most cases, I think.

@tannergooding this is the issue I pinged you about offline...

Left some comments above that talked about things both ways.

The TL;DR is that we want to propagate if possible for consistency, but there is no strict requirement to do so and it is still compliant if a runtime canonicalizes their NaN results (most just don't because its faster to not).

WASM recommends that implementations do propagate matching the IEEE 754 spec and anything that isn't will have the same issue for x + y or Truncate(x), etc. So us not guaranteeing Max(NaN, y) returns the exact NaN input is then consistent with the general WASM experience on such a target (WASM guaranteeing some NaN returns for such a case is all that's actually needed, technically speaking).

/ba-g android timeouts