wasm: prefer pmin/pmax

[myfreeer]

According to emscripten and v8, [f32x4|f64x2].[min|max] compiles to much more instructions than [f32x4|f64x2].[pmin|pmax]. It is defined in spec that the difference between pmin/pmax and min/max is NaN-propagating behavior, and the equivalent to the x86 _mm_min_ps/_mm_max_ps is pmin/pmax in v8. This should make functions with min/max faster on webassembly, and align with the existing behavior with x86 sse.

[recp]

@myfreeer many thanks for contributions for WASM support and its stability, the PR is merged 🚀

[gottfriedleibniz]

Should we aim for consistent Nan-propagating behaviour here? The Intel ISA states:

If only one value is a NaN (SNaN or QNaN) for this instruction, the second operand (source operand), either a NaN or a valid floating-point value, is written to the result.

From the V8 link above:

The maxps instruction doesn't propagate NaNs and +0's in its first operand

Therefore to match _mm_max_ps(a, b): wasm_f32x4_pmax(a, b) should be wasm_f32x4_pmax(b, a). For example, consider:

vec4 a, b, c;

glm_vec4_broadcast(NAN, a);
glm_vec4_broadcast(0.0, b);
glm_vec4_maxv(a, b, c);

printf("%f %f %f %f\n", c[0], c[1], c[2], c[3]);

// SSE: 0.000000 0.000000 0.000000 0.000000
// WASM: nan nan nan nan
// ARM: Another can of worms

Generalizing the above: should these functions follow x86 behaviour, IEEE behaviour, or just aim for maximum performance ignoring these edge-cases.

[recp]

@gottfriedleibniz many thanks for catching edge-cases like this and help to fix them.

I think we can wrap min/max by glmm_ e.g. glmm_min() and glmm_max() to make behaviors identical