Refactor relaxed ops spec

[rossberg]

I'm in the process of merging Relaxed SIMD into the wasm-3.0 branch. As part of that, this PR applies tweaks to the specification of relaxed operators:

• Refine how implementation-defined semantics is expressed by making all global parameters to the semantics explicit
• Refactor and simplify some definitions (especially laneselect)
• Fix some minor bugs (e.g., Relaxed truncation not specified for infinities relaxed-simd#157, Possible bug in spec of relaxeddotmul relaxed-simd#158)
• Adjust op names so that they are correctly picked up by the conventions defined in the instruction section
• Reorder definitions to match earlier sections (sorry for the diff mess-up!)

@ngzhian, could you please have a look?

[rossberg]

FWIW, I noticed that there is no correlation between the implementation choices of the semantics for fmin and fmax. Should there be? With the explicit global parameters, that would now be easy to express.

[ngzhian]

took a quick look, LG, thanks for the fixes! I would get @dtig to look more (i don't work on this anymore)

[ngzhian]

FWIW, I noticed that there is no correlation between the implementation choices of the semantics for fmin and fmax. Should there be? With the explicit global parameters, that would now be easy to express.

based on WebAssembly/relaxed-simd#33, yes fmin and fmax should be correlated.

[dtig]

Paging this back in, will take a closer look tomorrow - the one thing I'm mildly uncomfortable (non-blocking) about is the detail around renaming host-dependent behavior to implementation-dependent, mostly because that doesn't capture the dependency on the host very well. I'm wondering what you think of including a non-normative implementation note in numerics.rst or somewhere else that's appropriate to capture that the fixed set of results are fully dependent on the host environment, and the hardware that the program is run on.

[rossberg]

@dtig, good point about calling that out. I added an implementation note. Let me know what you think.

FWIW, there are multiple reasons why I rephrased from host-dependent to implementation-dependent. For one, we have been using "host" quite ambiguously, referring to different things, including either platform or embedder. In the spec, I so far tried to only use it the sense of embedder, which is not what it was referring to here.

Then, from a semantic perspective, it is not generally meaningful to differentiate where a semantic choice is coming from. It may not be the host environment, e.g., consider an emulator. Whether an implementation uses fast hardware behaviour is a performance / quality-of-implementation property.

Moreover, there are valid reasons for implementations to decide against exposing host behaviour — the deterministic profile is the obvious example. We deliberately allow that, hence "host-dependent" arguably is too specific to describe the space of choices.

Does that make sense?

[dtig]

The rephrasing to implementation-dependent makes sense, thanks for articulating the reasons for the change. I think the note clarifying the expectations captures for implementations here bridges the gap between what we were looking at previously as host-specific. Thanks for adding the note.