Is V128 restricted to wasm or Global?

[codefromthecrypt]

In the current specification, javascript is restricted from any external function definitions that include a v128 value type

Calling an Exported Function will throw a TypeError, when parameters or results contains a v128.

https://github.com/WebAssembly/spec/blob/f5a260a2025ba4d7d398654581c7c532e3a2c319/proposals/simd/SIMD.md#module-function-imports

Moreover, the host test only includes V128 as a global type (not a func type)

VecType V128Type -> Vec (V128 (V128.I32x4.of_lanes [666l; 666l; 666l; 666l]))

https://github.com/WebAssembly/spec/blob/f5a260a2025ba4d7d398654581c7c532e3a2c319/interpreter/host/spectest.ml

It seems like there's an implicit rule that host functions shouldn't use the V128 type, which can make sense as vectorizing via the host feels like it would never be performant. OTOH, there is exposing a global of V128 which is strange without rationale.

Can you please clarify the following?

1. Are languages besides javascript supposed to support V128 param or results and why?
2. What is the use case for a V128 global?

[codefromthecrypt]

I did some digging around implementations and still can't figure out the use case for a V128 global.

However, I do see evidence of v128 being unsupported even outside javascript cc @alexcrichton I would really like to have this point clarified before the next draft of the core spec https://github.com/bytecodealliance/wasmtime/blob/321124ad21e40927934c2bee34293019aeca8035/crates/wasmtime/src/func.rs#L1120

[rossberg]

Wasm modules can import and export functions or globals using v128 without problems. Only JavaScript can't access it. But it can still instantiate e.g. one Wasm module exporting a v128 global and then another importing that.

[codefromthecrypt]

ok so lack of implementation in wasmtime is not something to read into gotcha.

Still would like to know the use case of a v128 global if anyone knows. v128 as defined as vector used for SIMD, doesn't make sense. v128 as opaque bytes for any reason (ex trace ID) makes sense, but it wouldn't make sense to have no means to define it in wasm except via vector initialization..

[rossberg]

Why wouldn't it make sense? From Wasm's perspective, it's no different from im/exporting, say, an f64. It's a fully transparent type as far as Wasm is concerned.

[codefromthecrypt]

I suppose what's different about v128 vs another routine type is that it is only defined in context of vectorization:

This makes it odd and curious why a global would have a v128 value. Do you think it is otherwise?

[rossberg]

Honestly, I don't understand what you are getting at. Maybe my other reply clarifies?

[codefromthecrypt]

what you pointed me to there re-enforces the use case of v128: "Numeric vectors are 128-bit values that are processed by vector instruction"

arbitrary use, like a global, would be something besides being processed by a vector instruction. If arbitrary use is intended, wouldn't we want to clarify docs to suggest that v128 is an opaque type most commonly used for vector instructions as opposed to what's implied (exclusively for vector instructions).

Otherwise, I guess you are suggesting that global is a practical way of supplying a parameter to an instruction like i16x8.mul. just that feels off.

I also appreciate that you are answering, but maybe if you don't know why v128 was special cased in javascript to be ok for global, but not host func, someone else can help answer that.

[rossberg]

A global does not "process" a value, if that's all you wonder about. It just stores it.

The JS API treats both globals and functions involving v128 alike: you can export both to JS, but you cannot access either in JS – you get a TypeError when calling a function or when accessing a global. But you can pass both to another Wasm module.

[codefromthecrypt]

I'll close this topic. Thanks for taking time to reply