Repository navigation
Avoid codegen layout noise by building Wasmtime with one CGU - #348
Merged
cfallin merged 1 commit intoOct 23, 2026
Merged
Conversation
Building Wasmtime with one codegen unit helps us avoid codegen layout noise across commits due to functions "randomly" being inlined or not across builds of different Wasmtime commits based on whether they are in the same CGU or not. We do *not* also enable LTO (or, equivalently, use Wasmtime's `--profile fastest-runtime`) because this would enable more "random" (across different Wasmtime commits): inlining noise between crates. With CGUs=1 and LTO disabled, the inlining boundary is very clear and related directly to the code we write and not our dependencies: anything within a crate is a candidate for inlining into function in that same crate, unless the function is marked `#[inline]` (or, in some cases, is generic) in which case it can be inlined across crates. Minimizing codegen layout noise across builds of mostly-the-same Wasmtime commits is important so that when we compare the performance of, say, the latest `HEAD` to `HEAD^`, we are not, as much as possible, measuring changes due to LLVM's heuristics that could just as easily happen with *any* commit on top of `HEAD^` and isn't actually related to what `HEAD` itself is doing.
opensource-fork-sync Bot
pushed a commit
to cla7aye15I4nd/opensource-bytecodealliance__wasmtime
that referenced
this pull request
Oct 22, 2026
…slicing (bytecodealliance#14940) Otherwise, changing CGU slicing can change whether these do or don't get inlined in practice, which makes for regressions on host-heavy benchmarks (e.g. benchmarks that spend a bunch of time in GC). Fixes bytecodealliance/are-we-fast-yet#8 See also bytecodealliance/sightglass#348
cfallin
approved these changes
Oct 23, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Building Wasmtime with one codegen unit helps us avoid codegen layout noise across commits due to functions "randomly" being inlined or not across builds of different Wasmtime commits based on whether they are in the same CGU or not.
We do not also enable LTO (or, equivalently, use Wasmtime's
--profile fastest-runtime) because this would enable more "random" (across different Wasmtime commits) inlining noise between crates. With CGUs=1 and LTO disabled, the inlining boundary is very clear and related directly to the code we write and not our dependencies: anything within a crate is a candidate for inlining into function in that same crate, unless the function is marked#[inline](or, in some cases, is generic) in which case it can be inlined across crates.Minimizing codegen layout noise across builds of mostly-the-same Wasmtime commits is important so that when we compare the performance of, say, the latest
HEADtoHEAD^, we are not, as much as possible, measuring changes due to LLVM's heuristics that could just as easily happen with any commit on top ofHEAD^and isn't actually related to whatHEADitself is doing.r? @cfallin