Nice! Are there no tests because we don't have the assembly printer support yet?

Mostly LGTM to me

• Remove Pass.h includes that are unnecessary now

pong

ping

Is this https://github.com/WebAssembly/simd/pull/27 ? Can you please include the spec (even if it's still an unmerged PR) in the CL description next time? LGTM.

LGTM. It's interesting that we can use MemIntrinsicNode for this purpose even if it's not an intrinsic...
(I guess we can also use MachineSDNode because we are effectively doing isel before we reach tablegen, but given that we've used it only in WebAssemblyISelDAGToDAG.cpp and we do most custom SIMD lowering in WebAssemblyISelLowering.cpp, this looks like a good trick.)

In D68889#1706857, @aheejin wrote:

Nice! Mostly LGTM.

Currently non-void blocks are only generated at the end of functions where the block return type needs to agree with the function return type, and that remains true for multivalue blocks. That invariant means that the actual signature does not need to be stored in the block signature MachineOperand because it can be inferred by WebAssemblyMCInstLower from the return type of the parent function.

I guess this is a tentative state before you implement the rest of the proposal in full, right? If other blocks are able to return multivalue, are we gonna change their operands to also take typeindex?

Nice! Mostly LGTM.

In D68527#1701774, @tlively wrote:

In D68527#1700939, @aheejin wrote:

If swizzles are a lot more complicated that v128.const in execution, doesn't that mean swizzles will likely to take longer to execute in wasm? Why the opposite?

Swizzles lower directly to hardware instructions so they are fast for engines to execute. But doing the same operation without a swizzle instruction would require a long sequence of other wasm instructions and therefore be slow to execute. Because this difference is large for swizzles it is a good idea to prefer to use them when possible.

We can make the decision based on whatever heuristic we want, but minimizing number of instructions seems like a good metric for now until we can run experiments to tune the selection algorithm.

Wouldn't minimizing the number of instruction be the same thing as minimizing the number of bytes, only more inaccurate?

LLVM produces a poison value if the dynamic swizzle indices are greater than the vector size, but the WebAssembly instruction sets the corresponding output lane to zero.

Where do we set those undef or poison lanes to zero?

• I remember before we had a somewhat complicated logic to calculate the number of bytes of total instructions of each case of the case we use v128.const and vs. when we use splats. Don't we need that anymore? Can we make the decision solely based the number of swizzles / consts / and splats?

Thank you! Done in r374015.

Merging this, because this crashes builds.

Rebase onto D68553

• Address comments

Mostly LGTM. By the way this contains diff of D67783 as well.

LGTM as long as they are not used, but I'd like to check with @sunfish to be sure as well.

+1 on erroring out on the backend side. And how about "wasm64 is not supported"? wasm64... is still a registered target in the frontend, so...

What are the default values for those if we unset them?

LGTM.

• Maybe we can lower these to these new instructions later? (I'm not very sure what the difference between versions with and without VECTOR, because the versions without VECTOR seem to be able to take vector arguments as well.)
• Will this simplify the complicated lowering of SIGN_EXTEND_INREG?