Questions of scope

[lars-t-hansen]

In general, I'd like us to explicitly include in our scope an examination of all post-mvp, pending, and rejected instruction proposals on the simd repo to see if any of the instructions that we rejected or did not advance for reasons of nonportability could be included under the umbrella of relaxation. (If some of them are eligible, champions may need to be found, but that's secondary.)

In particular, I'm wondering where we might be with instructions that have tricky semantics wrt not just NaN behavior, rounding, or approximation, which are fairly benign problems, but have differences eg in saturation behavior, such as 8x16 -> 16x8 multiply-add, see https://github.com/WebAssembly/simd/issues/328. (We have an ML application in-house that depends on this instruction; thus far, the developers have been given access to a private instruction so as not to be blocked by its absence in wasm simd, but it's a problem I think relaxed SIMD needs to solve.)

The charter and yesterday's (very nice) presentation do not quite own up to the possibility that there are interesting instructions that are more or less completely platform-specific, where we can't paper over the differences with wording about platform-dependent accuracy. Do we consider these instructions in scope?

[ngzhian]

In general, I'd like us to explicitly include in our scope an examination of all post-mvp, pending, and rejected instruction proposals on the simd repo to see if any of the instructions that we rejected or did not advance for reasons of nonportability could be included under the umbrella of relaxation.

That's a good idea. We will need to come up with this list of instructions, probably transfer them over from WebAssembly/simd.

We will also need to discuss (pretty early), how we want to deal with platform-specificity. To handle such instructions we would need to introduce the equivalent of a platform detection flag, otherwise it doesn't seem like applications will be able to get correct results.

Comparing this to the example given in the presentation about float-to-int conversion (trunc sat behavior), it is possible for applications to behave in a platform independent way if they can guarantee the floats don't overflow.

[jlb6740]

@lars-t-hansen @ngzhian I do like the idea of sort of a post mortem of problematic rejected SIMD lowerings that possibly could be mitigated here. That said I wonder about relaxed SIMD turning into a dumping ground for new platform specific SIMD proposals which may not be helpful for promoting and encouraging instructions to first try to be platform neutral. If the vision allows or encourages platform-specificity then that's ok, that's the vision. But I agree that if it is not, then the question of how to prevent this should be answered first with some upfront guidelines/definition on what constitutes a relaxed SIMD instruction.

[ngzhian]

That said I wonder about relaxed SIMD turning into a dumping ground for new platform specific SIMD proposals which may not be helpful for promoting and encouraging instructions to first try to be platform neutral.

Excellent point. I think a section in Overview.md highlighting this point will help. Our goal is performance, and as a virtual ISA, in many cases we cannot paper over the differences between actual hardware. Perhaps indirectly we will encourage platform-specificity, but like you said we should look closely at whether we can avoid that.