wasmtime-winch: Use `wasmtime_environ::error` instead of `anyhow` (#12205)

Further refactor `TrampolineCompiler` for the wasm ABI (#11939)

* Further refactor `TrampolineCompiler` for the wasm ABI

This is a follow-up to #11932 where the `TrampolineCompiler` type is
further

Further refactor `TrampolineCompiler` for the wasm ABI (#11939)

* Further refactor `TrampolineCompiler` for the wasm ABI

This is a follow-up to #11932 where the `TrampolineCompiler` type is
further specialized to just working with the wasm ABI instead of trying
to multiplex two ABIs now that the array ABI is handled by calling the
wasm ABI. This involved purging the `self.abi` field and updating all
callers as appropriate.

This then performed some small refactoring to use `TrampolineCompiler`
for compiler intrinsics. Unsafe intrinsics also now have the same
strategy of calling the wasm ABI trampoline when compiling for the array
ABI. This should ensure that all entry trampolines are going through the
same function.

* Refactor short-circuit in inlining

* Update crates/wasmtime/src/compile.rs

Co-authored-by: Joel Dice <[email protected]>

---------

Co-authored-by: Joel Dice <[email protected]>

show more ...

Implement unsafe intrinsics for compile-time builtins (#11825)

* Implement unsafe intrinsics for compile-time builtins

This commit adds the extremely unsafe
`wasmtime::CodeBuilder::expose_unsafe_in

Implement unsafe intrinsics for compile-time builtins (#11825)

* Implement unsafe intrinsics for compile-time builtins

This commit adds the extremely unsafe
`wasmtime::CodeBuilder::expose_unsafe_intrinsics` method. When enabled, the Wasm
being compiled is given access to special imports that correspond to direct,
unchecked and unsandboxed, native load and store operations. These intrinsics
are intended to be used for implementing fast, inline-able versions of WASI
interfaces that are special-cased to a particular host embedding, for example.

Compile-time builtins, as originally described in [the
RFC](https://github.com/bytecodealliance/rfcs/pull/43), are basically made up of
three parts:

1. A function inliner
2. Unsafe intrinsics
3. Component composition to encapsulate the usage of unsafe intrinsics in a safe
interface

Part (1) has been implemented in Wasmtime and Cranelift for a little while
now (see `wasmtime::Config::compiler_inlining`). This commit is part (2). After
this commit lands, part (3) can be done with `wac` and `wasm-compose`, although
follow up work is required to make the developer experience nicer and more
integrated into Wasmtime so that the APIs can look like those proposed in the
RFC.

* fill out some more docs

* fix non component model builds

* start filling out the doc example

* Factor abi params/returns out; truncate/extend pointers

* Compile unsafe intrinsics on winch as well

* prtest:full

* have the macro define the signature

* ignore tests in MIRI because MIRI can't compile Wasm

* juggle pointer provenance in `Store::data[_mut]`

* add a test for store data provenance and also fix it

* use `VmPtr` for the store data pointer

* finish writing unsafe intrinsics example

* fix up docs and rules around only accessing data from `T` in a `Store<T>`

* Only reserve space for the intrinsics' `VMFuncRef`s if they are in use

* use dangling pointers instead of options

* Rename `StoreInner::data` to `data_no_provenance` and fix some accesses to use the method accessors

* Add comments about the provenance juggling inside `StoreInner::data[_mut]`

* only compile intrinsics that are used

Turns out we don't need to add phases, we already have the info available to do
this.

* fix duplicate symbol names

show more ...

Wasmtime: implement debug instrumentation and basic host API to examine runtime state. (#11769)

* Wasmtime: implement debug instrumentation and basic host API to examine runtime state.

This PR impl

Wasmtime: implement debug instrumentation and basic host API to examine runtime state. (#11769)

* Wasmtime: implement debug instrumentation and basic host API to examine runtime state.

This PR implements ideas from the [recent RFC] to serve as the basis
for Wasm (guest) debugging: it adds a stackslot to each function
translated from Wasm, stores to replicate Wasm VM state in the
stackslot as the program runs, and metadata to describe the format of
that state and allow reading it out at runtime.

As an initial user of this state, this PR adds a basic "stack view"
API that, from host code that has been called from Wasm, can examine
Wasm frames currently on the stack and read out all of their locals
and stack slots.

Note in particular that this PR does not include breakpoints,
watchpoints, stepped execution, or any sort of user interface for any
of this; it is only a foundation.

This PR still has a few unsatisfying bits that I intend to address:

- The "stack view" performs some O(n) work when the view is initially
taken, computing some internal data per frame. This is forced by the
current design of `Backtrace`, which takes a closure and walks that
closure over stack frames eagerly (rather than work as an
iterator). It's got some impressive iterator-chain stuff going on
internally, so refactoring it to the latter approach might not
be *too* bad, but I haven't tackled it yet.

A O(1) stack view, that is, one that does work only for frames as
the host API is used to walk up the stack, is desirable because some
use-cases may want to quickly examine e.g. only the deepest
frame (say, running with a breakpoint condition that needs to read a
particular local's value after each step).

- It includes a new `Config::compiler_force_inlining()` option that is
used only for testing that we get the correct frames after
inlining. I couldn't get the existing flags to work on a Wasmtime
config level and suspect there may be an existing bug there; I will
try to split out a fix for it.

This PR renames the existing `debug` option to `native_debug`, to
distinguish it from the new approach.

[recent RFC]: https://github.com/bytecodealliance/rfcs/pull/44

* Update to new APIs on Cranelift side.

* Test update.

* Adjust objdump printing of InstPos on frame progpoints; and adjust progpoint collapsing.

* Convert to iterator form.

* Fix path in native-debug tests (debug -> native_debug rename).

* Enforce that `debug_instrumentation` can only be enabled when feature is enabled.

* Add missing assert.

* Use builtin knob for forcing intra-module inlining instead.

* Review feedback:

- Make StackView own the current frame rather than handing it out. This
prevents the current frame (`FrameView`) from walking away and hiding
somewhere it shouldn't, to be used unsoundly later.
- Assert no-GC during stack walk.

* Merge debug-instrumentation hooks on FuncEnvironment into before/after hooks.

* Review feedback: avoid downcasting funcs twice.

* Add debug feature to `wasmtime` crate's defaults.

* Review feedback: u32s for local and stack indices in debug host API.

* Use *const u8 as stack pointers and `with_exposed_provenance` in debug API.

* Remove some `srcloc` plumbing in Wasm translator.

* Rename native-debug back to debug, and make the new thing "guest debugging".

* rustfmt in debugging test.

* fix disas test after guest-debug CLI option rename.

* Review feedback: no separate debug-instrumentation hooks on FuncEnvironment.

* Review feedback: update doc comment on `Config::guest_debug`.

* Review feedback: rename `generate_debuginfo` to `debug_native` in tunables.

* Review feedback: miscellaneous comments.

* Review comment: fix wording in safety conditions.

* revert wasi-common submodule update

* Properly root values in debug frame slots.

Fixes #11841.

* Fix non-`debug`-feature build.

* Review feedback: naming.

* Ignore tests that compile modules in miri.

show more ...

Fix compiler inlining tunables (#11797)

* Fix compiler inlining tunables

Fixes https://github.com/bytecodealliance/wasmtime/issues/11784

* fix no-compiler warning

Remove `AllCallFunc` (#11694)

* Remove `AllCallFunc`

And add `FuncKeyKind` and `FuncKeyNamespace` types.

Split out from https://github.com/bytecodealliance/wasmtime/pull/11630

* fix warning and d

Remove `AllCallFunc` (#11694)

* Remove `AllCallFunc`

And add `FuncKeyKind` and `FuncKeyNamespace` types.

Split out from https://github.com/bytecodealliance/wasmtime/pull/11630

* fix warning and disriminant gap

* add module arg to `Module::new()` calls in tests

show more ...

Make Wasmtime's `FuncKey` one-to-one with Cranelift's `ir::UserExternalName` (#11415)

* Make Wasmtime's `FuncKey` one-to-one with Cranelift's `ir::UserExternalName`

`FuncKey`, which used to be call

Make Wasmtime's `FuncKey` one-to-one with Cranelift's `ir::UserExternalName` (#11415)

* Make Wasmtime's `FuncKey` one-to-one with Cranelift's `ir::UserExternalName`

`FuncKey`, which used to be called `CompileKey`, is now one-to-one with
`cranelift_codegen::ir::UserExternalName`, and is used for not just identifying
compilation objects but also relocations and call-graph edges. This allows us to
determine the `StaticModuleIndex` and `DefinedFuncIndex` pair for any
`cranelift_codegen::ir::FuncRef`, regardless of inlining depth, which fixes some
fuzz bugs on OSS-Fuzz.

This continues pushing on the idea that Wasmtime's compilation orchestration and
linking should be relatively agnostic to the kinds of things it is actually
compiling and linking, allowing us to tweak, add, and remove new kinds of
`FuncKey`s more easily. Adding a new `FuncKey` should not require modifying
relocation resolution, for example, just a little bit of code to run the
associated compilation and optionally some code to extract metadata into our
final artifacts for querying at runtime. Everything in between should Just
Continue Working. We still aren't all the way there yet, but this does bring us
a little bit closer.

Finally, in Cranelift's inlining pass, this adds a check that a block is
inserted in the layout before attempting to remove it from the layout, which
would otherwise cause panics. This was triggered by multi-level inlining and
now-unreachable blocks in the inner callees.

I'll note that this does update basically all of the disas tests, or at least
nearly all of them that make function calls. This is because the namespace/index
numbering pair changed slightly to align with `FuncKey`, but that should pretty
much be the only changes.

* remove debug info from panic message, it is only available in some `cfg`s

* fill out module doc comment

* Fix compilation without `component-model` feature

* Fix some more cfg compilations

* cargo fmt

* fix a wrong `&dyn Any` auto coercion; add helpful debug logging and assertions for this kind of thing

show more ...

Wasmtime: Add (optional) bottom-up function inlining to Wasm compilation (#11283)

* Wasmtime: Add (optional) bottom-up function inlining to Wasm compilation

This commit plumbs together two pieces o

Wasmtime: Add (optional) bottom-up function inlining to Wasm compilation (#11283)

* Wasmtime: Add (optional) bottom-up function inlining to Wasm compilation

This commit plumbs together two pieces of recently-added infrastructure:

1. function inlining in Cranelift, and
2. the parallel bottom-up inlining scheduler in Wasmtime.

Sprinkle some very simple inlining heuristics on top, and this gives us function
inlining in Wasm compilation.

The default Wasmtime configuration does not enable inlining, and when we do
enable it, we only enable it for cross-component calls by default (since
presumably the toolchain that produced a particular core Wasm module, like LLVM,
already performed any inlining that was beneficial within that module, but that
toolchain couldn't know how that Wasm module would be getting linked together
with other modules via component composition, and so it could not have done any
cross-component inlining). For what it is worth, there is a config knob to
enable intra-module function inlining, but this is primarily for use by our
fuzzers, so that they can easily excercise and explore this new inlining
functionality.

All this plumbing required some changes to the `wasmtime_environ::Compiler`
trait, since Winch cannot do inlining but Cranelift can. This is mostly
encapsulated in the new `wasmtime_environ::InliningCompiler` trait, for the most
part. Additionally, we take care not to construct the call graph, or any other
data structures required only by the inliner and not regular compilation, both
when using Winch and when using Cranelift with inlining disabled.

Finally, we add a `disas` test to verify that we successfully inline a series of
calls from a function in one component, to a cross-component adapter function,
to a function in another component. Most test coverage is expected to come from
our fuzzing, however.

* Fix dead code warning when not `cfg(feature = "component-model")`

* fix winch trampoline compilation

* Move CLI options to codegen

* Move parameters into struct

* Use an index set for call-graph construction

* Smuggle inlining heuristic options through cranelift flags

* Remove old CLI flags

* set tunables before settings

* Only configure inlining options for cranelift in fuzzing

show more ...