Materialize the section on "Long SIMD".

[sunfishcode]

This is meant to address the original concern in
WebAssembly/spec#41

[jfbastien]

What happens when code uses long SIMD on a hardware platform which doesn't support it?

[sunfishcode]

Good question. I added it.

[xorgy]

Since I'm unable to comment on #1075, I'd like to say that fixed-width packed SIMD has a complicated relationship with RISC-V. I'm working on V8 for RISC-V (and presumably somebody will end up working on SpiderMonkey for RISC-V).

There is a Packed SIMD extension for RISC-V, but interest in implementing it is mixed. The preferred method of addressing vectors seems to be the Vector extension, which is variable-width and handles element counts which are not a multiple of the stride in hardware, rather than relying on software.

There are five major things that come to mind:

• I can imagine that compiling a RISC-V Vector kind of description to hardware-specific packed SIMD operations would be considerably simpler than pattern matching arbitrarily-implemented loops containing packed SIMD operations to extract a high level vector computation.

• I think it could get tedious adding different fixed width packed SIMD operations to WebAssembly, only to need to add another set when Intel comes out with 1024-bit, then 2048-bit packed SIMD. Each time we will have to do the web standards compatibility dance all over again, leaving developers to guess whether or not SIMD of a specific width will be supported on the majority of their users' machines and browser versions by the time they ship their code.

• Accounting for targets where specific vector operations either will not (for staffing or other practical reasons) or can not be implemented natively (hardware that does not have packed SIMD of any length) would be rather silly.

• The static code size of a truly platform-independent web assembly object will explode as the number of levels of packed SIMD instructions supported increases. This leaves application developers holding the bag: either they offload the cost of multiple codepaths on the network, or they opt to design elaborate infrastructure to build, detect, and serve many different binaries depending on variables that can only be determined after page load.

• Noting all of this, it still may be worth shipping packed SIMD instead, just because of how much software is written against it.

[NWilson]

I'm sure RISC-V is very nice... but realistically only x86 and ARM matter for the immediate term :( What's more compelling perhaps is that ARM is getting variable-width SIMD soon via "Scalable Vector Extension" (and I was chatting some people from the ARM compilers team at an LLVM developer meetup, who were enthusiastic about it). LLVM doesn't support variable-width SIMD yet, but it is being worked on currently. In the long run, it's probably the most future-proof way of adding these instructions. A target that only has fixed width SIMD can use that to implement variable-width Wasm instructions, but it's a bit harder going the other way round.

[jfbastien]

The right place to discuss SIMD, and bring up limitations to the proposed approach, is in the SIMD repo. Tracking issues are purposefully closed because they're informative, for tracking purpose, and not for discussion. The repo is where development and discussion happen.