Wasmtime GitHub notifications bot (Jul 18 2025 at 22:58): Wasmtime GitHub notifications bot (Jul 18 2025 at 22:58):fitzgen opened PR #11283 from fitzgen:wasmtime-inlining to bytecodealliance:main:
This commit plumbs together two pieces of recently-added infrastructure:
- function inlining in Cranelift, and
- 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 newwasmtime_environ::InliningCompilertrait, 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
disastest 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.Depends on https://github.com/bytecodealliance/wasmtime/pull/11282
Wasmtime GitHub notifications bot (Jul 18 2025 at 22:58):fitzgen requested alexcrichton for a review on PR #11283.
Wasmtime GitHub notifications bot (Jul 18 2025 at 22:58):fitzgen requested wasmtime-fuzz-reviewers for a review on PR #11283.
Wasmtime GitHub notifications bot (Jul 18 2025 at 22:58):fitzgen requested wasmtime-compiler-reviewers for a review on PR #11283.
Wasmtime GitHub notifications bot (Jul 18 2025 at 22:58):fitzgen requested wasmtime-core-reviewers for a review on PR #11283.
Wasmtime GitHub notifications bot (Jul 18 2025 at 23:03):fitzgen updated PR #11283.
Wasmtime GitHub notifications bot (Jul 18 2025 at 23:06):fitzgen updated PR #11283.
Wasmtime GitHub notifications bot (Jul 18 2025 at 23:23):fitzgen updated PR #11283.
Wasmtime GitHub notifications bot (Jul 19 2025 at 02:25):github-actions[bot] commented on PR #11283:
Subscribe to Label Action
cc @fitzgen, @saulecabrera
<details>
This issue or pull request has been labeled: "cranelift", "fuzzing", "wasmtime:api", "wasmtime:config", "winch"Thus the following users have been cc'd because of the following labels:
- fitzgen: fuzzing
- saulecabrera: winch
To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.
Learn more.
</details>
Wasmtime GitHub notifications bot (Jul 19 2025 at 03:13):github-actions[bot] commented on PR #11283:
Label Messager: wasmtime:config
It looks like you are changing Wasmtime's configuration options. Make sure to
complete this check list:
[ ] If you added a new
Configmethod, you wrote extensive documentation for
it.<details>
Our documentation should be of the following form:
```text
Short, simple summary sentence.More details. These details can be multiple paragraphs. There should be
information about not just the method, but its parameters and results as
well.Is this method fallible? If so, when can it return an error?
Can this method panic? If so, when does it panic?
Example
Optional example here.
```</details>
[ ] If you added a new
Configmethod, or modified an existing one, you
ensured that this configuration is exercised by the fuzz targets.<details>
For example, if you expose a new strategy for allocating the next instance
slot inside the pooling allocator, you should ensure that at least one of our
fuzz targets exercises that new strategy.Often, all that is required of you is to ensure that there is a knob for this
configuration option in [wasmtime_fuzzing::Config][fuzzing-config] (or one
of its nestedstructs).Rarely, this may require authoring a new fuzz target to specifically test this
configuration. See [our docs on fuzzing][fuzzing-docs] for more details.</details>
[ ] If you are enabling a configuration option by default, make sure that it
has been fuzzed for at least two weeks before turning it on by default.[fuzzing-config]: https://github.com/bytecodealliance/wasmtime/blob/ca0e8d0a1d8cefc0496dba2f77a670571d8fdcab/crates/fuzzing/src/generators.rs#L182-L194
[fuzzing-docs]: https://docs.wasmtime.dev/contributing-fuzzing.html
<details>
To modify this label's message, edit the <code>.github/label-messager/wasmtime-config.md</code> file.
To add new label messages or remove existing label messages, edit the
<code>.github/label-messager.json</code> configuration file.</details>
Wasmtime GitHub notifications bot (Jul 21 2025 at 18:37):fitzgen updated PR #11283.
Wasmtime GitHub notifications bot (Jul 22 2025 at 22:37):alexcrichton created PR review comment:
Should this extend into a set instead of a vec?
Wasmtime GitHub notifications bot (Jul 22 2025 at 22:37):alexcrichton created PR review comment:
To bikeshed a bit, what about
-Cinstead and dropping thecompiler_*prefix?
Wasmtime GitHub notifications bot (Jul 22 2025 at 22:37):alexcrichton created PR review comment:
Given the quantity of parameters here and how this is probably going to get tuned over time, how about packaging this all up in
struct InlineDecisionParams { .. }or something like that? That way there's named keys and no need to worry about getting things in the wrong order by accident.
Wasmtime GitHub notifications bot (Jul 22 2025 at 22:37):alexcrichton created PR review comment:
How come these are doc(hidden)?
Wasmtime GitHub notifications bot (Jul 22 2025 at 22:37):alexcrichton submitted PR review.
Wasmtime GitHub notifications bot (Jul 22 2025 at 22:37):alexcrichton created PR review comment:
These can probably all be ignored, right? Regardless of what the host and artifact have configured the artifact should still work the same way? (e.g. inlining doesn't affect abi)
Wasmtime GitHub notifications bot (Jul 22 2025 at 22:37):alexcrichton created PR review comment:
An alternative to this perhaps, the
LinkOptions::padding_between_functionsfield is a "compiler setting" but layered on top of Cranelift sort of. These sorts of options might make sense there too? That might require pushing more deduction of whether to inline into theInliningCompilertrait but that seems reasonable. That way we get-Ccranelift-...options for everything and don't have to have customConfigmethods.
Wasmtime GitHub notifications bot (Jul 28 2025 at 18:08):fitzgen submitted PR review.
Wasmtime GitHub notifications bot (Jul 28 2025 at 18:08):fitzgen created PR review comment:
That would require sorting just to be safe w.r.t. non-determinism and also propagating a dependency on hashbrown up to wasmtime-environ. Neither is really a problem, but they are both a little annoying. Pair this with the fact that the deduplication shouldn't matter, since we are creating call-graph edges based on the imported funcs arena and not based on call instructions, and we deduplicate the former during Wasm-to-CLIF construction, I don't think it is worth switching this from a vec to a set.
Wasmtime GitHub notifications bot (Jul 28 2025 at 18:14):fitzgen submitted PR review.
Wasmtime GitHub notifications bot (Jul 28 2025 at 18:14):fitzgen created PR review comment:
Yeah, this is true but I figured the safest, most conservative thing to do here was to require them to be identical, so that's what I did out of an abundance of caution. If you feel strongly, I can remove these checks and ignore these options.
Wasmtime GitHub notifications bot (Jul 28 2025 at 18:17):fitzgen updated PR #11283.
Wasmtime GitHub notifications bot (Jul 28 2025 at 19:45):alexcrichton submitted PR review.
Wasmtime GitHub notifications bot (Jul 28 2025 at 19:45):alexcrichton created PR review comment:
I think
IndexSetin wasmtime-environ would solve that? Basically I'm worried about big-O factors here of making a very large list of effectively all callsites.
Wasmtime GitHub notifications bot (Jul 28 2025 at 19:48):fitzgen created PR review comment:
Basically I'm worried about big-O factors here of making a very large list of effectively all callsites.
We already dedupe imported functions when building the CLIF so we don't need to worry about the big-O factors here. But it would be more future proof, I suppose.
Wasmtime GitHub notifications bot (Jul 28 2025 at 19:48):fitzgen submitted PR review.
Wasmtime GitHub notifications bot (Jul 28 2025 at 20:38):fitzgen updated PR #11283.
Wasmtime GitHub notifications bot (Jul 28 2025 at 20:38):fitzgen commented on PR #11283:
@alexcrichton okay, this should be ready for a second look
Wasmtime GitHub notifications bot (Jul 28 2025 at 21:01):alexcrichton submitted PR review.
Wasmtime GitHub notifications bot (Jul 28 2025 at 21:01):alexcrichton created PR review comment:
I think these can be removed now?
Wasmtime GitHub notifications bot (Jul 28 2025 at 21:11):fitzgen updated PR #11283.
Wasmtime GitHub notifications bot (Jul 28 2025 at 21:11):fitzgen submitted PR review.
Wasmtime GitHub notifications bot (Jul 28 2025 at 21:11):fitzgen created PR review comment:
Good eye, thanks
Wasmtime GitHub notifications bot (Jul 28 2025 at 21:11):fitzgen has enabled auto merge for PR #11283.
Wasmtime GitHub notifications bot (Jul 28 2025 at 22:17):fitzgen updated PR #11283.
Wasmtime GitHub notifications bot (Jul 28 2025 at 22:17):fitzgen has enabled auto merge for PR #11283.
Wasmtime GitHub notifications bot (Jul 29 2025 at 14:59):alexcrichton merged PR #11283.
Last updated: Dec 06 2025 at 06:05 UTC