Some SIMD operations are not well defined yet. For instance, SIMD.float32x4.min/max semantics are not defined precisely in the polyfill if one of the operands is NaN, or if the operands are -0 and 0. This is not the place to discuss the specification, but we'll need to make sure to tie close to the spec once it's stable and public. Things potentially needed to change, for min/max: - tests and implementation in the interpreter (jstests, SIMD.h/cpp) - CodeGeneratorX86Shared::visitSimdBinaryArith, min/max sections [0] https://github.com/johnmccutchan/ecmascript_simd/issues/51

Adding bugs as dependent that will likely be impacted by changes in the spec, to be sure to update all of these once the spec is more stable: - min/max: what happens with -0/0, NaN? - int32x4.fromFloat32x4(): what happens if one input's lane can't be converted into an int32?

Bug 1073064: What do we do for shifts >31?

For shifts > 31, see also the spec issue: https://github.com/johnmccutchan/ecmascript_simd/issues/72

Bug 1044256 for precision of float32x4.reciprocal{,sqrt}. See also https://github.com/johnmccutchan/ecmascript_simd/issues/71

Bug 1094855 takes care of updating min/max everywhere.

For float-to-int conversions, see also https://github.com/johnmccutchan/ecmascript_simd/issues/99

This has to be address before inlining SIMD.int32x4.fromFloat32x4 function in IonMonkey, otherwise fuzzers will complain about differential behaviour, as the interpreted function has the TypeObject semantic, and the SIMD operation has the metal semantic.

Seems all sub-bugs have been fixed and there's no other big issue I can think about, in our current implementation. Dan, any other specification issue we have in our current implementation, or can I mark this bug as resolved fixed?

I'm not aware of any other issues at the moment. If we discover anything, we can file a new bug.

Thanks for your input, let's close it then!