- Use "true" and "false" instead of "1" and "0"
- "nonzero" -> "non-zero"
- "returns true if ... or false if ..." -> "returns true ..., false
otherwise"
This intrinsic doesn't have any preconditions and is always safe to
call, so it can be safe.
This function is already stable, but dropping `unsafe` is a backwards
compatible change.
Note tha we already have a precedent for wasm intrinsics being safe --
wasm simd is safe.
It is relatively practically important to mark this safe --
wasm32::unreachable is directly useful in practice as more codesize
efficient `panic!()`.
Those intrinsics have the correct semantics for the desired fcvtz instruction,
without any undefined behaviour. The previous simd_cast was undefined for
infinite and NaN which could cause issues.
Wasmtime now supports all of the simd proposal, so this commit
uncomments instruction assertions and tests, while also adding more
tests, for all wasm simd instructions. This means that all wasm simd
instructions should be tested and have running instruction assertions,
except for `i64x2.abs`, which will require an LLVM upgrade to LLVM 13.
This allows us to deprecate the crypto target_feature in favour of its
subfeatures.
We cannot do this yet for ARM targets as LLVM requires the crypto
feature. This was fixed in
b8baa2a913
Now that `transmute` can be flagged as `const`-stable this commit
updates the `f32x4` and `f64x2` constructors as `const`-stable as well.
This also additionally rewrites the other integer constructors in a more
readable fashion now that the general `v128()` method is `const`-stable.
Since most intrinsics are safe it likely makes sense to explicitly
document why there are a few intrinsics that are not safe. These
intrinsics are all unsafe for the same reason, which is that they're
dealing with a raw pointer that must be valid to load/store memory to.
Note that the are no alignment requirements on any of these intrinsics.
