Fix `ExtendedOpcode::MAX` for Pulley (#12867)

This was off-by-one which could lead to possible undefined behavior in
Miri and at runtime when disassembling invalid opcodes. This isn't
reachable from

Fix `ExtendedOpcode::MAX` for Pulley (#12867)

This was off-by-one which could lead to possible undefined behavior in
Miri and at runtime when disassembling invalid opcodes. This isn't
reachable from Wasmtime itself since Cranelift only generates valid
opcodes, but it's nonetheless reachable via `wasmtime objdump` and still
good to fix.

show more ...

Update nightly rust used in CI (#11388)

In addition to keeping things up-to-date this enables testing the
`tail_loop` interpreter mode of Pulley using the `become` keyword and
native Rust syntax. Th

Update nightly rust used in CI (#11388)

In addition to keeping things up-to-date this enables testing the
`tail_loop` interpreter mode of Pulley using the `become` keyword and
native Rust syntax. This still isn't ready for prime-time so it's just
as gated as before, but we can promote a `cargo check` to a `cargo test`
in CI.

show more ...

Update Wasmtime to the 2024 Rust Edition (#10806)

* Update Wasmtime to the 2024 Rust Edition

Now that our MSRV supports the 2024 edition it's possible to make this
switch. This commit moves Wasmtim

Update Wasmtime to the 2024 Rust Edition (#10806)

* Update Wasmtime to the 2024 Rust Edition

Now that our MSRV supports the 2024 edition it's possible to make this
switch. This commit moves Wasmtime to the 2024 Edition to keep
up-to-date with Rust idioms and access many of the edition features
exclusive to the 2024 edition.

prtest:full

* Reformat with the 2024 edition

show more ...

pulley: Remove `unwrap_uninhabited` helper function (#10174)

No longer needed on our MSRV any more.

Add basic support for profiling Pulley (#10034)

* Add basic support for profiling Pulley

This commit adds basic support for profiling the Pulley interpreter.
This is partially achievable previously

Add basic support for profiling Pulley (#10034)

* Add basic support for profiling Pulley

This commit adds basic support for profiling the Pulley interpreter.
This is partially achievable previously through the use of native
profilers, but the downside of that approach is that you can find hot
instructions but it's not clear in what context the hot instructions are
being executed nor what functions are hot. The goal of this profiler is
to show pulley bytecode and time spent in bytecode itself to better
understand the shape of code around a hot instruction to identify new
macro opcodes for example.

The general structure of this new profiler is:

* There is a compile-time feature for Pulley which is off-by-default
where, when enabled, Pulley will record its current program counter
into an `AtomicUsize` before each instruction.

* When the CLI has `--profile pulley` Wasmtime will spawn a sampling
thread in the same process which will periodically read from this
`AtomicUsize` to record where the program is currently executing.

* The Pulley profiler additionally records all bytecode through the use
of the `ProfilingAgent` trait to ensure that the recording has access
to all bytecode as well.

* Samples are taken throughout the process and emitted to a
`pulley-$pid.data` file. This file is then interpreted and printed by
an "example" program `profiler-html.rs` in the `pulley/examples`
directory.

The end result is that hot functions of Pulley bytecode can be seen and
instructions are annotated with how frequently they were executed. This
enables finding hot loops and understanding more about the whole loop,
bytecodes that were selected, and such.

* Add missing source file

* Check the profile-pulley feature in CI

* Miscellaneous fixes for CI

* Fix type-checking of `become` on nightly Rust

* Fix more misc CI issues

* Fix dispatch in tail loop

* Update test expectations

* Review comments

* Fix a feature combo

show more ...

pulley: Add simple debugging support (#9796)

This commit adds a `debug.rs` to Pulley to print out the instruction
being executed and the state of all registers between instructions. This
is turned o

pulley: Add simple debugging support (#9796)

This commit adds a `debug.rs` to Pulley to print out the instruction
being executed and the state of all registers between instructions. This
is turned off by default and does not have a runtime or
environment-based configuration value. Instead changing this requires
changing source code for now. This enables the interpreter loop to
unconditionally use this "debugger" where it'll compile away to nothing
in release/benchmarking situations.

This commit additionally adds this support to the `tail_loop` module and
fixes a few issues there such as it accidentally not being tested in CI
as well as a new `#[cfg]` to use it on stable rust with normal `return`
under the assumption that LLVM is highly likely to do TCO.

show more ...

Refactor Pulley's interpreter loop (#9629)

* Refactor Pulley's interpreter loop

* Define loop-over-match and loop-with-tail-calls in separate files to
make it more clear which is in which (and le

Refactor Pulley's interpreter loop (#9629)

* Refactor Pulley's interpreter loop

* Define loop-over-match and loop-with-tail-calls in separate files to
make it more clear which is in which (and less `#[cfg]`)
* Move per-opcode handlers to `interp.rs` outside of a macro invocation
to get better native editor support (e.g. formatting, hints, etc).

This is roughly intended to be perf-neutral but we don't have many
automated benchmarks yet for Pulley so it's intended to profile later as
well.

* Model interpreter as trait implementation

* Add more comments

show more ...