Overloading of RMW and wait operations

As @rossberg brought up in https://github.com/WebAssembly/shared-everything-threads/pull/110#pullrequestreview-4080081246 and as we discussed at the recent CG meeting, the current design overloads the new RMW and wait operations to work with several types. For example struct.atomic.rmw.add x y works on both i32 and i64 fields. This does not violate our principal types properties because the type of the field is determined by the type and field immediates x and y. However, the execution of the instruction needs to handle addition on both i32 and i64 fields in a way we have historically avoided, by e.g. making i32.add and i64.add separate instructions. (Although it is the case that separating i32.add and i64.add is necessary to preserve principal types as well.)

The "no overloading" rule is also already somewhat fuzzy in practice. Instructions like ref.is_null are parametric over all heap types, so need to handle comparisons with potentially different null values and representations for each heap type hierarchy. Instructions like struct.get obviously have different implementations for different field types in real implementations, even if the spec can be written to handle all types generically.

So I argue that the "no overloading" rule is not buying us much in practice, and it would be well worth dropping it to reduce the need to introduce dozens of new instructions. We won't immediately descend into chaos because we still have the principal types properties imposing order on the instruction set.

In the CG meeting, @titzer raised the point that in-place interpreters need to do extra work when instructions are overloaded. @kmiller68 said he would have to go see how this would affect the JSC interpreter. My question is: given that these interpreters already have to handle e.g. struct.get, is it really worth adding dozens of instructions to save them this work on instructions that will be much less common than struct.get?

Start by reading the linked pull request review and the discussion summarized from the CG meeting. Compare the interpreter concerns raised by the participants with the current overloaded RMW and wait operations. Done requires an agreed design decision on whether to retain or remove the no-overloading rule, rather than a localized code change.