search

WebAssembly / simd

Branch of the spec repo scoped to discussion of SIMD in WebAssembly
Other
530 stars 43 forks source link

Is v128 a "number type"? #363

Closed kripken closed 4 years ago

kripken commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

~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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

tlively commented 4 years ago

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 commented 4 years ago

FWIW, I join the consensus.

rossberg commented 4 years ago

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 commented 4 years ago

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.