In the imported Wasm spec tests we are using wasmGlobalsEqual a lot. The F32/F64 values at the moment are wrongfully asserted as equal. See https://searchfox.org/mozilla-central/source/js/src/builtin/TestingFunctions.cpp#1270

Yikes, that's a bad mistake. Can you do a try run to gather some test failures triggered by fixing this?

Here is a list of failing tests if I replace one aVal with bVal:
wasm/spec/memory64/address64.wast.js
wasm/spec/memory64/float_memory64.wast.js
wasm/spec/spec/address.wast.js
wasm/spec/spec/conversions.wast.js
wasm/spec/spec/f32_bitwise.wast.js
wasm/spec/spec/f64_bitwise.wast.js
wasm/spec/spec/float_exprs.wast.js
wasm/spec/spec/float_memory.wast.js
wasm/spec/spec/float_misc.wast.js
wasm/spec/spec/local_tee.wast.js
wasm/spec/spec/select.wast.js
wasm/spec/spec/simd_f32x4.wast.js
wasm/spec/spec/simd_f64x2.wast.js
wasm/spec/spec/simd_lane.wast.js

Most of fails are: -0 vs 0, nan vs -nan, or payload are not equal in nan.

Problem is actually with WasmLosslessInvoke. And to be exact with StoreRegisterResult that is doing canonicalizeFloat/canonicalizeDouble in the compiled stubs (see also GenerateInterpEntry). We need to change WasmLosslessInvoke logic to not rely on StoreRegisterResult logic to canonicalize the register results.

I'm thinking about removal of wasmLosslessInvoke and replacing it with just a simple proxy module with mutable globals and function that wraps the callee.

The wasm/spec/spec/simd_f32x4.wast.js and wasm/spec/spec/simd_f64x2.wast.js (0 vs -0) cases are addressed by the bug 1799014.

https://hg.mozilla.org/mozilla-central/rev/90096eecbde7