Instruction names

[ngzhian]

So far in Overview.md we've just been calling the instructions "relaxed X", where X is the original Wasm SIMD instruction. We probably should come up with proper instruction names which will go into the text format.

[ngzhian]

I think that the relaxed-simd instructions name should reflect the non-determinism, e.g. i8x16.laneselect_relaxed or i8x16.laneselect_something. It should not be simply i8x16.laneselect. Any thoughts?

(There was also a comment about i32x4.trunc_sat_f32x4_{s,u}, that sat should not be in the name, that's noted and when we come up with a convention we can fix that.)

[Maratyszcza]

I don't think relaxed instructions need to have any special indication of their architecture-specific nature in the name. Emscripten wouldn't generate Relaxed SIMD instructions unless they are explicitly enabled, and this is sufficient to ensure they are not used unexpectedly.

[Maratyszcza]

As for naming, I suggest the following:

• qfma for relaxed fma instructions
• qmin/qmax for relaxed min/max instructions
• laneselect for relaxed blend instructions
• i32x4.trunc_f32x4_s/i32x4.trunc_f32x4_u/i32x4.trunc_f64x2_s_zero/i32x4.trunc_f64x2_u_zero for relaxed floating-point to integer conversions
• qswizzle for relaxed swizzle instruction

[ngzhian]

Emscripten wouldn't generate Relaxed SIMD instructions unless they are explicitly enabled, and this is sufficient to ensure they are not used unexpectedly.

You can use wasm_simd128.h to access these instructions (probably, unless we aren't going to add them in for some reason), and we would like authors to be aware of the architecture-specific nature of these instructions. Assuming they exist in the header, having matching instruction names in the text format will be good.

I quite like the q prefix, although it's not easy to explain what "quasi" means (I myself did not know of this term until you proposed QFMA).

[tlively]

We could also put the intrinsics for these instructions in a new header to help users differentiate between them, but I know I would personally find it helpful as someone who looks at a lot of Wasm if the relaxed instructions did have some naming convention to distinguish them from the deterministic instructions.

[lars-t-hansen]

For as much as I like the brevity of the q prefix, and for as much as that matches the current p prefix of pmax/pmin, I suspect we would be better off in the long term if we spelled out rel, relax, or relaxed, and in that case a suffix is probably the least visually disturbing and creates the maximum symmetry with existing instructions, ie fNxM.max_relaxed.

(For that matter, we could discuss whether pmax and pmin might have less obscure names. Back in WebAssembly/simd#122 these started out as qmax and qmin but were subsequently renamed after a brief debate about the meaning of "quasi"; there was no discussion about whether a one-letter prefix was the best thing. Seen in a larger context, fNxM.max_asymmetric would be the appropriate rendering, maybe.)

[penzn]

I feel like adding 'relaxed' to instruction names would become somewhat confusing when those get standardized, as there is no explicitly 'strict' instruction subset and the distinction between current and relaxed semantics would be somewhat lost.

[lars-t-hansen]

I feel like adding 'relaxed' to instruction names would become somewhat confusing when those get standardized, as there is no explicitly 'strict' instruction subset and the distinction between current and relaxed semantics would be somewhat lost.

The meaning of "relaxed" would just be "unspecified behavior (more than just indeterminate NaN bits) for some of its input range", and that could be captured in a definition somewhere. It's also nice to keep the word since it points back to the present proposal. I've no objection to looking for a different word that better / more intuitively captures the meaning. My main point is that almost anything would be an improvement over having to keep explaining the difference between "pseudo" and "quasi" and having to map a single-character prefix to those words.

[rossberg]

I agree that it would be desirable if non-determinism (beyond NaN) was self-identifying in the instruction mnemonic.

[ngzhian]

I propose this naming convention: <type>.relaxed_<instruction_name>.

• keeps the "relaxed" word, pointing back to this proposal
• makes it clear that's something about this instruction that is different
• <instruction_name> hints at the instructions in SIMD proposal (if it exists, like swizzle, trunc, min, max, q15mulr_s).
• any sat suffix is removed, since the instructions don't saturate

E.g. i8x16.relaxed_swizzle, i32x4.relaxed_trunc_f32x4_s, i8x16.relaxed_laneselect, f32x4.relaxed_fma, f64x2.relaxed_min, i16x8.relaxed_q15mulr_s

I feel like adding 'relaxed' to instruction names would become somewhat confusing when those get standardized, as there is no explicitly 'strict' instruction subset and the distinction between current and relaxed semantics would be somewhat lost.

The meaning of "relaxed" would just be "unspecified behavior (more than just indeterminate NaN bits) for some of its input range", and that could be captured in a definition somewhere.

The meaning of "relaxed" will be described in the spec text, specifically under Execution/Numerics, see the draft here https://www.ngzhian.com/relaxed-simd/core/exec/numerics.html#relaxed-operations. I need to tweak the paragraph because it mentions "host-dependent", and doesn't tie it in to the word "relaxed" (besides the heading of the paragraph).