RGB2Y | Fastest CPU RGB to grayscale : 2-4x faster | Computer Vision library

Copying my answer from the Emscripten issue:

The reason we don't use v128.const for this is that v128.const was only recently implemented in V8. To avoid breaking origin trial users, we can't update LLVM to emit v128.const until the relevant V8 patches roll into Chrome stable. I'm keeping an eye on this dashboard to determine when will be a good time to make this change. If you're using a more recent build of Chrome or some other execution environment that does support v128.const, you can try compiling your project with the -munimplemented-simd128 flag, which will enable v128.const in LLVM (but might also introduce other changes that you don't want). Once v128.const is widely available, it will be better for LLVM to use v128.const than to load vectors from memory because that allows the engine to determine the best way to materialize vectors given the runtime platform.

It also might be worth considering porting performance-sensitive parts of your code to use the WebAssembly intrinsics header directly rather than relying on emulated SSE. That would reduce a layer of impedence mismatch between your code and the underlying machine code.

Finally, if you notice suboptimal instruction selection anywhere, it would be helpful if you could file LLVM bugs (if it's on the code -> wasm side) or V8 bugs (if it's on the wasm -> native side) about the specific issues you see. That kind of feedback is extremely valuable to us.