This commit avoids the usage of blend-related instructions when the
SSE4.1 feature is not available. This means that `bitselect` uses the
less optimal lowering and additionally the `x86_blendv` instruction is
disabled for relaxed simd lowerings based on whether SSE4.1 is available
or not (falling back to the deterministic lowering which is supported if
it's not available).
Additionally the `iabs` implementation for i64x2 was updated to have a
non-blend-based lowering, modeled after LLVM.
* riscv64: Add Newtypes for Registers
* riscv64: Add Typesafe Register Wrappers to scalar lowerings
* riscv64: Remove ValueRegs to Reg Rule
* riscv64: Revert `gen_select_reg` signature
`gen_select_reg` can only compare X registers, but can move F registers based on that decision.
Adjust the type signature to reflect that.
Also add some lowering tests to cover these cases.
* Add adapter build to dependency for the entire CI build
* Build adapter on PR CI when it changes
* Update adapter verification for new stdin/stdout/stderr
* Update reactor build script
* Reduce some duplication with some shared variables
* Rename adapters to `wasi_snapshot_preview1.{reactor,command}.wasm`
* Fix upload pattern
Changes include:
- Add new insecure and insecure-seed random APIs. Also, change the
random test to avoid depending on the secure random API returning
deterministic data.
- Split stdio into separate interfaces for stdin, stdout, and stderr.
- Add `access-at` to wasi-filesystem.
- Update the sockets wit files to the new non-blocking-style API.
* x64: Swap order of operands in EVEX instructions
This commit updates the `src1`/`src2`/... operand orderings to match
those of other XMM/VEX instructions. This should also match Intel's own
documentation for numbered registers in instruction encodings.
* Fix tests
* Fix register allocation of `XmmRmREvex`
This commit is a follow up to https://github.com/bytecodealliance/wasmtime/pull/6443,
in which we discussed potentially having `PtrSize` and `ABI` as
associated types to the `MacroAssembler` trait.
I considered having `PtrSize` associated to the `ABI`, but given the
amount of ABI details needed at the `MacroAssembler` level, I decided to
go with the approach in this change.
The chosen approach ended up cutting a decent amount of boilerplate from
the `MacroAssembler` itself, but also from each of the touchpoints where
the `MacroAssembler` is used.
This change also standardizes the signatures of the `ABI` trait. Some of
them borrowed `&self` and some didn't, but in practice, there's no need
to have any of them borrow `&self`.
* x64: Add memory operand support to EVEX instructions
Currently load-sinking is enabled for EVEX instructions (aka AVX512
instructions) but the encoding of these instructions is a `todo!()`
which can cause a panic for some wasms if the right features are
enabled. This commit fills out the support for memory operands in the
same manner as VEX-encoded instructions. The main stickler here was that
EVEX instructions always use a scaled 8-bit offset which needed extra
handling to ensure that the correct offset is emitted.
* Pass scaling to `Imm` construction
* Review comments
* Fix tests
* Fix evex benchmark
This commit is a small cleanup to drop the usage of the `FuncEnv` trait.
In https://github.com/bytecodealliance/wasmtime/pull/6358, we agreed on
making `winch-codegen` directly depend on `wasmtime-environ`.
Introducing a direct relatioship between `winch-codegen` and
`wasmtime-environ` means that the `FuncEnv` trait is no longer serving
its original purpose, and we can drop the usage of the trait and use the
types exposed from `winch-codegen` directly instead.
Even though this change drops the `FuncEnv` trait, it still keeps
a `FuncEnv` struct, which is used during code generation.
* winch(fuzz): Refactor Winch's fuzzing
This change is a follow-up to the discussion in
https://github.com/bytecodealliance/wasmtime/pull/6281.
The most notable characteristic of this change is that it enables
`winch` by default in the fuzzers. If compilation time is a big enough
concern I can add the cargo feature back. I opted to enable `winch` by
default for several reasons:
* It substantially reduces the `cfg` complexity -- at first I thought
I had covered all the places in which a `cfg` check would be needed,
but then I realized that I missed the Cranelift specific compiler
flags.
* It's the fastest route to enable winch by default in the fuzzers,
which we want to do eventually -- the only change we'd need at that
point would be to get rid of the winch-specific environment variable.
* We can get rid of the winch-specific checks in CI for fuzzing
* Implement Arbitraty for CompilerStrategy
Unconditionally return `Cranelift` for the `Arbitrary` implementation of
`CompilerStrategy`. This ensures that `Cranelift` is used as the
compiler for all the targets unless explicitly requested otherwise. As
of this change, only the differential target overrides the
`CompilerStrategy`
* Filetest: allow "expect-fail" compile tests.
This mode allows us to test that we properly error out of compilation
situations where compilation should not be possible. It does not assert
anything about the specific error produced, just that a compile error
occurred.
* Add filetest for #6431.
* Cranelift/ABI: catch overflow in layout code with large stack slots.
This PR catches and successfully errors out of compilation a situation
where stackslots exceed the `u32` (4GB) range of the stack-frame layout
computation.
Note that this is not reachable from Wasmtime (it does not use
stackslots) so does not have security implications there, but could
cause issues in other compilers (e.g. cg\_clif) that pass arbitrary
stackslot sizes to Cranelift.
* winch(trampolines): Save SP, FP and return address
This change is a follow-up to https://github.com/bytecodealliance/wasmtime/pull/6358
This change implements the necessary stores of SP, FP and return address
for fast stack walking.
* Ignore backtrace test on Windows
Temporarily ignoring Winch's trap test on Windows while
support for unwind information is added.
* Remove some yanked crates from `Cargo.lock`
This commit fixes some warnings that are cropping up during publishing
about yanked crates being in our `Cargo.lock`.
* Remove an unneeded vet `imports.lock` entry
I was curious how `deserialize` compared with `deserialize_file`. There was
already a `bench_deserialize_module` so I expanded it to support `deserialize`.
Some results:
```
Benchmarking deserialize/deserialize/wasi.wasm
Benchmarking deserialize/deserialize/wasi.wasm: Warming up for 3.0000 s
Benchmarking deserialize/deserialize/wasi.wasm: Collecting 100 samples in estimated 5.4918 s (50k iterations)
Benchmarking deserialize/deserialize/wasi.wasm: Analyzing
deserialize/deserialize/wasi.wasm
time: [107.44 µs 108.00 µs 108.56 µs]
Found 9 outliers among 100 measurements (9.00%)
6 (6.00%) high mild
3 (3.00%) high severe
Benchmarking deserialize/deserialize_file/wasi.wasm
Benchmarking deserialize/deserialize_file/wasi.wasm: Warming up for 3.0000 s
Benchmarking deserialize/deserialize_file/wasi.wasm: Collecting 100 samples in estimated 5.0337 s (56k iterations)
Benchmarking deserialize/deserialize_file/wasi.wasm: Analyzing
deserialize/deserialize_file/wasi.wasm
time: [89.572 µs 89.705 µs 89.872 µs]
Found 14 outliers among 100 measurements (14.00%)
9 (9.00%) high mild
5 (5.00%) high severe
```
* Update release date of Wasmtime 9.0.0
* Update release date
---------
Co-authored-by: Wasmtime Publish <wasmtime-publish@users.noreply.github.com>
Co-authored-by: Alex Crichton <alex@alexcrichton.com>
* riscv64: Support vector instruction masking
* riscv64: Add `vmerge` instructions
* riscv64: Implement `insertlane`
* riscv64: Fix encoding of `vmv` instructions
Some of these carry their source in vs2
* riscv64: Fix formatting of mask register
Remove the space between , and the register. This
is inline with the rest of our formatting.
* riscv64: Restrict `insertlane` to vector types that fit in a single register
* wasmtime: Enable more RISC-V SIMD tests
* riscv64: Use inline format syntax for printing vector instructions
* riscv64: Add vector mask note
This fuzz target was accidentally broken by #6378 and I forgot to update
this fuzz target. Namely all the generated types now need names to
satisfy possible restrictions depending on the structure. For simplicity
everything is given a name to avoid having to special case some vs
others which isn't the purpose of this fuzz target.
this is causing a link error because pulldown_cmark is available both in
the rust_wasi_markdown_parser deps directory and, now, in the root of
the project as well.
Many of the tests for lowering features use `extractor`s I think since
when they were added that was the only option. Nowadays a `pure
constructor` with `if-let` feels more natural for this, so this commit
updates all existing extractors used to test features to use a `pure
constructor` instead. This additionally updates the names to match the
cranelift codegen setting name to ensure that a consistent name is used.
This is an unnecessary restriction: applications shouldn't be relying on
any ordering of preview1 fds, besides that other files are not found in
the stdio range.
This behavior changed with the introduction of the component adapter,
but I am making a separate PR to edit the test rather than make it part
of #6391.
Roman Volosatovs
Alex Crichton
Afonso Bordado
Dan Gohman
Ian Ker-Seymer
Saúl Cabrera
Lukas Forst
Tyler Rockwood
Jeffrey Charles
Trevor Elliott
Chris Fallin
Marcin S
wasmtime-publish
Nick Fitzgerald
Andrew Gutekanst
Pat Hickey
Pat Hickey