This changes wasm simd intrisnics which deal with memory to match clang
where they all are emitted with an alignment of 1. This is expected to
not impact performance since wasm engines generally ignore alignment as
it's just a hint. Otherwise this can increase safety slightly when used
from Rust since if an unaligned pointer was previously passed in that
could result in UB on the LLVM side. This means that the intrinsics are
slighly more usable in more situations than before.
It's expected that if higher alignment is desired then programs will not
use these intrinsics but rather the component parts. For example instead
of `v128_load` you'd just load the pointer itself (and loading from a
pointer in Rust automatically assumes correct alignment). For
`v128_load64_splat` you'd do a load followed by a splat operation, which
LLVM should optimized into a `v128.load64_splat` instruction with the
desired alignment. LLVM doesn't fully support some optimizations (such
as optimizing `v128.load16_lane` from component parts) but that's
expected to be a temporary issue. Additionally we don't have a way of
configuring the alignment on operations that otherwise can't be
decomposed into their portions (such as with `i64x2_load_extend_u32x2`),
but we can ideally cross such a bridge when we get there if anyone ever
needs the alignment configured there.
Naming right now for wasm simd intrinsics takes the signededness of the
instruction into account, but some operations are the same regardless of
signededness, such as `i32x4_add`. This commit adds aliases for all of
these operations under unsigned names as well (such as `u32x4_add`)
which are just a `pub use` to rename the item as two names. The goal of
this is to assist in reading code (no need to switch back and forth
between `i` and `u`) as well as writing code (no need to always remember
which operations are the same for signed/unsigned but only available
under the signed names).
First change them all to unsigned since they're just returning bits, and
then also change them to the smallest-size integer which fits the return
value (`u16` for `i8x16_bitmask` and `u8` for everything else). This
suffers from an LLVM codegen bug for now, but it will hopefully get
fixed in the not too distant future.
This round is dependant on
https://github.com/rust-lang/llvm-project/pull/101 landing first in
rust-lang/rust and won't pass CI until that does. That PR, however, will
also break wasm CI because it's changing how the wasm target works. My
goal here is to open this early to get it out there so that when that PR
lands in rust-lang/rust and CI breaks in stdarch then this can be merged
to make CI green again.
The changes here are mostly around the codegen for various intrinsics.
Some wasm-specific intrinsics have been removed in favor of more general
LLVM intrinsics, and other intrinsics have been removed in favor of
pattern-matching codegen.
The only new instruction supported as part of this chagne is
`v128.any_true`. This leaves only one instruction unsupported in LLVM
which is `i64x2.abs`. I think the codegen for the instruction is correct
in stdsimd, though, and LLVM just needs to update with a pattern-match
to actually emit the opcode. That'll happen in a future LLVM update.
* Uncomment some i64-related instruction assertions now that LLVM
supports the opcodes.
* Fix the codegen for `{i,u}32x4_trunc_sat_f32x4`. This was originally
introduced using `simd_cast` but that inherits LLVM's UB related to
float-to-integer casts out of bounds. Since the original inception of
these intrinsics in LLVM dedicated intrinsics for the wasm
instructions have been added, so this swithces the implementation to
using those.
* Uncomment `f64x2_convert_low_i32x4` instruction assertion and add a
test now that this is implemented in Wasmtime.
