wasm: Make simd types passed via indirection again

[alexcrichton]

This commit updates wasm target specs to use simd_types_indirect: true
again. Long ago this was added since wasm simd types were always
translated to v128 under-the-hood in LLVM, meaning that it didn't
matter whether that target feature was enabled or not. Now, however,
v128 is conditionally used in codegen depending on target features
enabled, meaning that it's possible to get linker errors about different
signatures in code that correctly uses simd types. The fix is the same
as for all other platforms, which is to pass the type indirectly.

[rust-highfive]

r? @Mark-Simulacrum

(rust-highfive has picked a reviewer for you, use r? to override)

[alexcrichton]

It's worth pointing out that this may have actually always been a bug and when I first implemented this I just didn't realize the impact of what I was doing. In any case the test added here fails on wasm today with a linking error, but I dont believe that it should.

It's possible perhaps to fix this in the codegen layer of LLVM by automatically enabling the simd128 feature whenever a vector type is used in the parameter/argument list, but that I think is more complicated than implementing this fix which works the same for all platforms. Note that performance isn't expected to be affected here since simd intrinsics rely on inlining for performance anyway, so it's extremely rare in practice to actually have a function call with a v128 argument or return value on the hot path.

[workingjubilee]

I discussed this extensively with Alex yesterday off-sides to clarify my understanding of the situation, but today I realized that constituted a review of the code and really, of the situation as-is, which this PR essentially is a confirmation of. Some comments to summarize that (chat|review):

0. A possible performance hit mostly isn't an issue here because whether wasm SIMD improves performance is up to the wasm runtime, not us, so our main concern is just making sure we don't pessimize things unduly.
1. LLVM should see through it anyways. If LLVM doesn't see through it, this is a concern on other architectures as well, so wasm is nothing special here.
2. Automatically enabling features might be an awkward solution, even if implemented, due to concerns about whether we correctly eschew inserting SIMD instructions when the programmer does not desire them. These concerns would be extremely minimal for wasm, tho'.
3. Ultimately the inciting issue to pay attention to, and the "real" one for someone to solve in future work, is -C target-feature/-C target-cpu are unsound #64609

@bors r+

[bors]

📌 Commit 55769a5 has been approved by workingjubilee