Comment #3 on issue 6020 by
bradn...@chromium.org: [wasm] Implement WebAssembly SIMD prototype
https://bugs.chromium.org/p/v8/issues/detail?id=6020#c3@talltyler
That's correct, you would only be able to use calls into wasm functions to indirectly handle SIMD types from JS (or pass them around in arraybuffers and access individual elements).
Most SIMD.js code we were able to find with performance wins is a variant on asm.js code, which requires carefully structured JS code, and which almost entirely comes from similar compilers to the sort used to generate wasm code.
The API surface for SIMD.js is enormous. Dropping it shaved 10% off V8's code size. And mind you this was just for the raw ability to implement the slow path for the API surface (no faster code than if you'd just done a polyfill).
Our initial plan for optimization had been to focus specifically on the proposed SIMD.js extension to asm.js. Ironically one unsettled aspect of that proposal is whether you can even call in and out of the module with SIMD types, which argues the feature was never really well structured to interact tightly with JS.
Realistically to get a meaningful win from SIMD, applications usually need to deal with whole arraybuffers full of SIMD values, rather than passing them around individually.
There are ways to optimize general SIMD.js mixed in, but lots of performance cliffs abound. That said, there are a few places where V8 uses a SIMD instruction here and there for non-explicit SIMD code.
Passing the values around might make sense as an ergonomic affordance, but would probably be better done as a part of one of the JS value type proposals floating around. Something similar is true for int64 values, which wasm can handle directly, but can't export directly to JS.
Out of curiosity, what sort of application were you considering it for?