Truncate over-large parameters to splat

[abrown]

• This has not been discussed in an issue as the bug is described here.
• A short description of what this does, why it is needed: while running the SIMD spec tests in wasmtime, I noticed incorrect results due to i32-sized integers passed to a splat to i8-sized lanes. The spec was undefined on what to do with the extra bits, so I opened an issue and associated PR on the spec repository. This change implements the general consensus to just truncate the extra bits.
• This PR contains test cases, if meaningful: see wasmtime SIMD spec tests.
• A reviewer from the core maintainer team has been assigned for this PR.

[sstangl]

The change does what it says. Thanks for linking the discussion!

The only thing I don't understand is why truncation isn't also applicable to a 64x2 -> 32x4 case. Is that implicit?

[abrown]

The only thing I don't understand is why truncation isn't also applicable to a 64x2 -> 32x4 case. Is that implicit?

In the spec they do pass i32 to the i8x16.splat and i16x8.splat but they do not do the same for i32x4.splat, e.g.--in that case they only ever pass an i32 and no larger. See the list of splat instructions: https://github.com/WebAssembly/simd/blob/master/proposals/simd/SIMD.md#create-vector-with-identical-lanes.

[sstangl]

In the spec they do pass i32 to the i8x16.splat and i16x8.splat but they do not do the same for i32x4.splat, e.g.--in that case they only ever pass an i32 and no larger. See the list of splat instructions: https://github.com/WebAssembly/simd/blob/master/proposals/simd/SIMD.md#create-vector-with-identical-lanes.

Is it worth asserting that those combinations can't occur?

[abrown]

@sstangl, I thought the asserts were a good idea and started to add them but then remembered that the Cranelift type system might already be doing this. In the splat definition, the value to splat is constrained to be the same type as the lane type of the returned vector. So if the value to splat doesn't match the lane type, we see the type error I was originally observing. I think we are ok without the asserts; your thoughts?

[abrown]

@sstangl, I'm going to merge and if you feel like we need assertions above and beyond the Cranelift type-checking then I can add them in a subsequent PR.