Is v128 a "number type"?

[kripken]

This came up in https://bugzilla.mozilla.org/show_bug.cgi?id=1666939#c5

Basically a "number type" in the original spec is i32, i64, f32, f64, and they can use the old select, while anything else must use the new select. SIMD is a new proposal so I guess it has the choice to add v128 to be a number type, or not?

Currently v128 seems to be accepted as a number type by V8 and Binaryen, but not SpiderMonkey.

[ngzhian]

Yes, I expect v128 to be a number type. In the current spec it is part of value_type (https://github.com/WebAssembly/simd/blob/master/interpreter/syntax/types.ml#L3) and in the reference-types proposal value_type splits into num_type and ref_type (https://github.com/WebAssembly/reference-types/blob/master/interpreter/syntax/types.ml#L3). I think merging these two proposals will place v128 into num_type.

[tlively]

This might have implications for Binaryen as well. IIRC, Binaryen currently treats v128 as a non-number "vector" type. We might want to change that to more exactly match the spec. Nevermind, Binaryen already has this correct.

[eqrion]

It seems reasonable to me to have v128 be a number type. The primary requirement for being usable in untyped select is that there isn't a non-trivial subtype relationship, which v128 satisfies.

The only argument I could see against this, is if we were treating the untyped select as 'deprecated' and wished to push new uses to the typed select instruction. I don't think this really is a necessary step, so I don't think it's a strong argument.

[rossberg]

I think this is mostly a terminology question. Given how non-uniform much of the SIMD structure is, I suspect that the spec will ultimately have to denote simple number types in some places not including SIMD and an extended class that does in others. If so, @ngzhian will figure it out.

I would be hesitant about allowing any new type in unannotated select. Who knows, maybe some day somebody want proposes shape-aware subtypes of v128? It's safest to treat unannotated select as a backward-compatibility hack and not extend its scope further, and it's not like we're losing anything with that.

[tlively]

Disallowing v128 with unannotated select would introduce an otherwise-unnecessary dependence on the reference-types proposal and would be a breaking change for existing SIMD users. Not that either of these are serious issues, but I want to point out that there are some small downsides of making that change.

[rossberg]

Fair enough, though reference types are "about to land soon" (sigh), so I wouldn't worry about the dependency.

[tlively]

We discussed this at the SIMD sync meeting just now and the general consensus among those present was that the path of least resistance was to have v128 be a number type. @lars-t-hansen and @rossberg, you weren't there to represent your opinions on this issue, so let me know if that doesn't seem reasonable to you. Otherwise, I think we can consider this settled.

[lars-t-hansen]

FWIW, I join the consensus.

[rossberg]

As I said, this is mostly a terminology question. It is "almost" a number type, but it has its differences, and there will inevitably be contexts in the spec where we'll need to make a distinction. So spec-wise we need a hierarchy with two separate names, whatever they are.

[tlively]

Since we have decided that v128 is a number type to the extent possible, I am going to close this issue. Please reopen or comment if there are any follow-on questions.