• Add script doc comment and update string formatting

• Switch to using MVT::Glue

@aheejin, there are no changes I am currently planning to make to this, but I am happy to continue the inline discussions.

• Rebase on master

Just looking for high-level feedback right now, especially on the inclusion of the script and generated test cases. Now that multivalue is testable, I will go back and clean up the previous patches in this chain.

Unfortunately I do not know how multi-return.ll works. Despite its name, it is not a multivalue test (although once multivalue works it would make sense to add a multivalue-enabled run to that file). I generally don't use test-generation scripts because they tend to produce tests with unclear goals, as you observe.

LGTM! I checked locally and this fixes https://github.com/rust-lang/rust/issues/66308. Thanks for solving this so quickly :)

• Use MVT::Other for link, rebase

• Add OpInfo check to avoid OOB when there are only variadic ops

• Check isVariadic explicitly in InstrEmitter

• Address simple comments

In D71484#1783994, @sbc100 wrote:

In the description you say " .. unique among upstream targets", and later "... WebAssembly and similar downstream targets.". Was it deliberate to use both "upstream" and "downstream", what do these term mean here? Also the "unique" statement seems to contract the "and similar" statement.

This issue is still not resolved.

LGTM, sorry for the delay!

• Add second argument

https://github.com/WebAssembly/simd/pull/127

LGTM!

This is https://github.com/WebAssembly/simd/pull/127

In D69696#1729676, @aheejin wrote:

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.

One other thought: Does the implementation in this diff care what type the reference type pointers are pointing to? It would be nice if we could enforce the use of an opaque pointee type to prevent the reference types from being dereferenced.

It would be great to see some test .ll files here so we can get a better understanding for what is implemented here. I would also like to see tests of what happens if you try to do a ptrtoint or some other illegal operation on a reference type.

I'm re-opening this revision. After discussion on https://github.com/WebAssembly/simd/issues/118, there is clear consensus that we do not want to break WebAssembly's abstraction and consider underlying platforms, so shuffles should not be merged without some sort of modification to the spec to serve as a platform-agnostic indication that the merged shuffle will be better.

• Address comments

In D68889#1708287, @aheejin wrote:

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?

• Explain more about multivalue types in WebAssembly::BlockType