* Cranelift: Stop sign-extending `Imm64` immediates in builder methods
Originally, we sign-extended `Imm64` immediates from their controlling type
var's width to `i64` in the builder methods for `BinaryImm64` and a couple other
instruction formats: https://github.com/bytecodealliance/wasmtime/pull/1687
At some point, we decided that the unused bits in the `Imm64` when the
controlling type var's width is less than 64 should be zero. And we started
asserting that in various places, for example:
87817f38a1/cranelift/codegen/src/machinst/lower.rs (L1237-L1243)
However, we never removed or updated the sign-extension code in the builder
methods. This commit switches the builder methods over to masking the `Imm64` to
just the valid bits, effectively doing a zero extend from the controlling type
var's width instead of a sign extend.
To avoid too much churn in tests, I made `display_inst` print the
sign-extended-from-the-controlling-type-variable's-width value of `Imm64`
immediates. I also made the `Display` implementation for `Imm64` always print in
decimal form with a `-` for negative numbers, rather than the hex it would
previously print for large negative numbers, so that `iconst.i32 0x8000_0000`
doesn't display as `iconst.i32 0xffff_ffff_8000_0000`, which is otherwise pretty
confusing.
* Rename condition
* return new immediates instead of mutating
* Update some test expectations
Don't rely purely on `compile_error!` which doesn't halt compilation.
Instead fill out some stubs which won't ever actually get compiled but
prevent other compiler errors from cropping up.
This fixes a crash where the `GetSp` opcode was overwriting a special
register, so apply a similar filter as to other instructions to ensure
that the special registers are not clobbered.
Also set their default levels to `warn` instead of `deny` to assist with
using clippy locally to avoid compilation failures and collecting as
many as possible in one run. Note that CI will still deny-by-default
through `-Dwarnings`.
Now that we've got CI for Pulley throw in `wasmtime-fiber` as well with
a few extra fixes. This should also help improve the compilation
experience of Wasmtime to 32-bit platforms to hit a more first-class
error about unsupported platforms.
This commit updates `build-test-matrix.js` to calculate PR tests to
never early-return `false`. The current structure for PR tests will
iterate over most matrix entries and filter them out based on whether
they're applicable or not given the commit message and modified files.
The thinking is that an early-return of `false` might be a
false-negative where a later filter enables the test. By only
early-returning `true` this enables any passing predicate to cause the
tests to be run on a PR. Note that this has no effect on merge queues
since those always and unconditionally run everything.
* Add an unsafe API to unload process trap handlers
This commit adds a new unsafe API `Engine::unload_process_handlers`
which can be used to de-initialize trap-handling state in a process. In
general this is an unsafe operation that we have no means of making
safe, hence the `unsafe`. There are particular situations where this can
be done safely though and this is provided for such situations. The
safety conditions rely on invariants that Wasmtime itself cannot
maintain so the burden is on callers to ensure that this is invoked in a
safe manner.
This is inspired by discussion [on Zulip][zulip] where Wasmtime's trap
handling infrastructure prevented unloading a DLL with Wasmtime in it.
There's possibly other reasons that unloading DLLs are unsafe in Rust
but it feels appropriate to at least provide this knob to embedders to
be able to turn if they like.
[zulip]: https://bytecodealliance.zulipchat.com/#narrow/stream/206238-general/topic/How.20to.20safely.20drop.20wasmtime.3F/near/453366905
* Review comments
* Update tests/unload-engine.rs
Co-authored-by: Nick Fitzgerald <fitzgen@gmail.com>
* Ignore new test on miri
---------
Co-authored-by: Nick Fitzgerald <fitzgen@gmail.com>
* Derive `Copy` for `Val`
* Fix `clippy::clone_on_copy` for the whole repo
* Enforce `clippy::clone_on_copy` for the workspace
* fix some more clippy::clone_on_copy that got missed
This removes `V128Abi`, which is no longer needed since we removed the native
calling convention from Wasmtime. For the new internal representation of `V128`,
we use an unaligned byte array. This lowers the alignment requirements for
`V128` to 1 rather than 16, which means that `Val` no longer requires padding
after its discriminant before the storage for its `V128` variant, which in turn
allows its size to shrink from 32 to 24 bytes.
Co-authored-by: Trevor Elliott <telliott@fastly.com>
* Add support for `-Wunknown-imports-trap` to components
This was implemented in #8672 and is an easy addition to the CLI.
Closes#9019
* Fix non-component CLI build
* Update gimli to 0.29.0
Gimli 0.29.0 includes a fix for corrupt .eh_frame unwind tables being
generated in certain cases. Wasmtime isn't affected by this as it never
sets an LSDA, but cg_clif will need this for supporting unwinding from
exceptions.
I also had to update a couple of other crates to prevent crates being
included in multiple versions.
* Add vets for new dependencies
---------
Co-authored-by: Alex Crichton <alex@alexcrichton.com>
* Pulley: Get tests passing with permissive provenance under MIRI
Co-Authored-By: Alex Crichton <alex@alexcrichton.com>
* Pulley: Get tests passing with strict provenance in MIRI
Co-Authored-By: Alex Crichton <alex@alexcrichton.com>
* Test Pulley under MIRI in CI
* Test Pulley with all cargo features in CI
* Quiet a warning for certain build configs
---------
Co-authored-by: Alex Crichton <alex@alexcrichton.com>
* CI: Check that Pulley builds for `no_std` targets
* CI: Test Pulley on 32-bit targets
This adds CI testing for Pulley on the following 32-bit targets:
* `i686-unknown-linux-gnu`
* `armv7-unknown-linux-gnueabihf`
The previous commit added checks that Pulley builds for `no_std` targets.
Our existing test sharding means that it is already tested on a big-endian
platform (`s390x-unknown-linux-gnu`) as well as on different OSes (Linux,
Windows, and macOS).
So altogether we are now testing a pretty wide range of portability dimensions
for Pulley in CI:
* 32- vs. 64-bit architectures
* `std` vs. `no_std`
* Little- vs. big-endian
* Linux vs. Windows vs. macOS
I think our CI coverage for Pulley is in a pretty good place now!
Co-Authored-By: Alex Crichton <alex@alexcrichton.com>
---------
Co-authored-by: Alex Crichton <alex@alexcrichton.com>
* Introduce the `pulley-interpreter` crate
This commit is the first step towards implementing
https://github.com/bytecodealliance/rfcs/pull/35
This commit introduces the `pulley-interpreter` crate which contains the Pulley
bytecode definition, encoder, decoder, disassembler, and interpreter.
This is still very much a work in progress! It is expected that we will tweak
encodings and bytecode definitions, that we will overhaul the interpreter (to,
for example, optionally support the unstable Rust `explicit_tail_calls`
feature), and otherwise make large changes. This is just a starting point to get
the ball rolling.
Subsequent commits and pull requests will do things like add the Cranelift
backend to produce Pulley bytecode from Wasm as well as the runtime integration
to run the Pulley interpreter inside Wasmtime.
* remove stray fn main
* Add small tests for special x registers
* Remove now-unused import
* always generate 0 pc rel offsets in arbitrary
* Add doc_auto_cfg feature for docs.rs
* enable all optional features for docs.rs
* Consolidate `BytecodeStream::{advance,get1,get2,...}` into `BytecodeStream::read`
* fix fuzz targets build
* inherit workspace lints in pulley's fuzz crate
* Merge fuzz targets into one target; fix a couple small fuzz bugs
* Add Pulley to our cargo vet config
* Add pulley as a crate to publish
* Move Pulley fuzz target into top level fuzz directory
* Bump MSRV to 1.78.0
This commit updates to use Rust 1.80 in CI as well as updating the
minimum-supported-rust-version to 1.78. Additionally the nightly used in
testing in CI is updated as well.
prtest:full
* Fix compat with latest nightly in tests
* Fix some more nightly warnings
* Ignore new tests on MIRI
* Cranelift(x64): Fix lowering for `store(bitop(x, load(addr)), addr)` for bitops on floats
x86-64 allows us to do these kinds of read-modify-write operations in one
instruction in general, however we also need to ensure that the non-memory
operand is in a GPR. Because Cranelift allows `b{and,or,xor}`s on floating point
types, that means we might need to insert a move from an XMM to a GPR.
Co-Authored-By: Jamey Sharp <jsharp@fastly.com>
* Match all GPR values in `put_in_gpr` and let assertion catch multi-reg values
Instead of backtracking.
---------
Co-authored-by: Jamey Sharp <jsharp@fastly.com>
* Cranelift(x64): provide better panic messages for `Gpr::new(reg).unwrap()` et al
Co-Authored-By: Jamey Sharp <jsharp@fastly.com>
* Fix compile error due to bad mechanical replacement
---------
Co-authored-by: Jamey Sharp <jsharp@fastly.com>
* Add v128.const support to Winch
* Remove next_vr and vector_reg_for methods
* Adjust alignment and slot size for v128
* Forgot to update disas tests
* Update unit tests
* Use 8 byte stack slot sizes
* Fix broken unit tests, add tests for vecs, and use ty size for vecs
* Fix test of wasmtime-fuzzing with `fuzz-pcc` enabled
Allow pcc errors when generating fuzz modules since it's currently gated
as the errors haven't all been weeded out.
* Gate wmemcheck instrumentation more in `wasmtime-cranelift`
This fixes an issue where when the `wmemcheck` feature was enabled it
would unconditionally enable the `wmemcheck`-related instrumentation
around `malloc` and `free`. The fix is to additionally check the runtime
`wmemcheck` setting as well.
Closes#8997
* Forward the `wmemcheck` feature from `wasmtime-cranelift` to `wasmtime-environ`
Not necessarily strictly required but it should help prevent issues
such as #8997 in the future.
* Move safepoints and stack maps tests to the `safepoints` module
* Add logging for the rewriting phase of user stack maps
* Fix a safepoints bug involving block parameters and cursor positions
We weren't setting the cursor position correctly after inserting spills for
block parameters that need inclusion in stack maps, which caused us to
accidentally skip over the first instruction in the block sometimes.
* clif in wasmtime explore
* clif in wasmtime explore: do not continue if clif directory exists
* clif in explorer: run prettier
* explorer: use flex instead of width
* explorer: fix scrolling
* explorer: use temp directory for clif
* explorer: tempfile is an optional dependency
* clif in explorer: do not display clif if compiling with winch
* Move safepoints and stack maps code to its own module
This is purely mechanical code motion.
* Shorten log messages' prefix
These are all inside a "safepoint" module, and `env_logger` prints the module
before the log message, so the old "stack map" part of the log messages' prefix
is a bit redundant now.
* Use a typed enum for stack slot sizes
Rather than an open-coded `u32`.
Addresses https://github.com/bytecodealliance/wasmtime/pull/8978#discussion_r1684809610
* Update some comments
These comments were referencing things that we did in the old implementation of
stack maps and safepoints, and have been updated for the new approach.
* cranelift-frontend: Support moving GCs with user stack maps
This refactors the way that user stack maps work such that they are compatible
with moving GCs. We now keep every GC value in a stack slot, spill to the stack
slot on the value's definition, and reload from the stack slot on every
use. This means that we can generate a bunch of redundant loads, but we let the
mid-end's alias analysis clean that up. This has the added benefit of reducing
the length of live ranges for GC values and also means we don't need to
proactively spill every single live GC values at each safepoint, because we know
they are already spilled. This latter bit actually helps us avoid an
accidentally quadratic issue with many, long, overlapping live ranges where we
would do `O(n^2)` spills for a series of safepoints that keep creating more GC
refs.
We also implement two further optimizations:
1. We lazily allocate slots for live GC values, which means that if a GC value
is not ever live across a safepoint, then we do never allocate a stack slot for
it and never spill it to the stack slot. If we didn't do this, then frames would
be larger and we'd have a dead store to the stack slot that would otherwise
require the mid-end to grow a dead-store-elimination pass.
2. We keep a free list of available slots that will never be used again, and we
reuse slots from here when possible. This means that a chain of non-overlapping
live ranges, each of which still needs to appear in some safepoint's stack map,
will all reuse the same stack slot, keeping frames from being bloated.
Finally, this commit also introduces some logs for the liveness analysis to ease
future debugging.
Co-Authored-By: Trevor Elliott <telliott@fastly.com>
* review feedback
---------
Co-authored-by: Trevor Elliott <telliott@fastly.com>
* winch: Improve scratch register handling
This commit doesn't introduce any new behavior. It's mostly a follow-up
to https://github.com/bytecodealliance/wasmtime/pull/7977.
This commit tries to reduce the repetitive pattern used to obtain the
scrtach register by introducing a macro similar to the existing `vmctx!`
macro.
This commit also improves the macro definition by using fully qualified
paths.
* Fix unused imports
* Remove the `readme` directive of the `cranelift-bitset` crate as the
file doesn't exist.
* Remove invalid categories of the `wasmtime-wasi-threads` crate that
aren't present on crates.io.
Nick Fitzgerald
beetrees
Xinzhao Xu
Alex Crichton
Vulcain
bjorn3
Jeffrey Charles
Afonso Bordado
Marceline Cramer
Isaac Foster
阿豪
Saúl Cabrera