Cranelift/Wasmtime: disable fastalloc (single-pass) allocator for now.#10554
Merged
cfallin merged 1 commit intobytecodealliance:mainfrom Apr 9, 2025
Merged
Conversation
fitzgen
approved these changes
Apr 8, 2025
c2a4900 to
c1ff5b1
Compare
Unfortunately, as discovered by a recent fuzzbug [1], the single-pass register allocator is not compatible with the approach to callsite defs that exception-handling support has forced us to take. In particular, we needed to move all call return-value defs onto the call instruction itself, so calls could be terminators; this unbounded number of defs is made to be a solvable allocation problem by using `any` constraints, which allow allocation directly into spillslots; but fastalloc appears to error out if it runs out of registers, regardless of this constraint. Long-term, we should fix this, but unfortunately I don't have cycles to dive into fastalloc's internals at the moment, and it's (I think) a tier-3 feature. As such, this PR disables its use for now. I've filed a tracking issue in RA2 [2], and referenced this in the Cranelift configuration option docs at least. To keep from shifting all fuzzbugs / fuzzing corpii by altering the `arbitrary` interpretation, I opted to keep the enum the same in the fuzzing crate, and remap `SinglePass` to `Backtracking` there. I'm happy to take the other approach and remove the option (thus invalidating all fuzzbugs) if we'd prefer that instead. [1]: https://oss-fuzz.com/testcase-detail/5433312476987392 [2]: bytecodealliance/regalloc2#217
c1ff5b1 to
2eeaa2a
Compare
Contributor
|
@cfallin are there plans to re-introduce |
Member
Author
|
@Robbepop the issue at bytecodealliance/regalloc2#217 describes the issue that is preventing us from re-enabling it. As of right now, I have no time to investigate or fix this; I am oversubscribed on too many other things that are higher-priority and that is unlikely to change for the rest of the year. If you or anyone else are willing to dig in and fix this, it would be very much appreciated! |
cfallin
added a commit
to cfallin/wasmtime
that referenced
this pull request
Aug 25, 2025
… for now. (bytecodealliance#10554)" This reverts commit d52e23b.
github-merge-queue bot
pushed a commit
that referenced
this pull request
Aug 25, 2025
…ble and add to testing. (#11533) * Revert "Cranelift/Wasmtime: disable fastalloc (single-pass) allocator for now. (#10554)" This reverts commit d52e23b. * Upgrade to regalloc2 0.13.1. Pulls in bytecodealliance/regalloc2#233 to update fastalloc to support the looser constraints needed by exception-related changes. * cargo-vet update.
bongjunj
pushed a commit
to prosyslab/wasmtime
that referenced
this pull request
Oct 20, 2025
…ble and add to testing. (bytecodealliance#11533) * Revert "Cranelift/Wasmtime: disable fastalloc (single-pass) allocator for now. (bytecodealliance#10554)" This reverts commit d52e23b. * Upgrade to regalloc2 0.13.1. Pulls in bytecodealliance/regalloc2#233 to update fastalloc to support the looser constraints needed by exception-related changes. * cargo-vet update.
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
3 participants
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.
Unfortunately, as discovered by a recent fuzzbug 1, the single-pass register allocator is not compatible with the approach to callsite defs that exception-handling support has forced us to take. In particular, we needed to move all call return-value defs onto the call instruction itself, so calls could be terminators; this unbounded number of defs is made to be a solvable allocation problem by using
anyconstraints, which allow allocation directly into spillslots; but fastalloc appears to error out if it runs out of registers, regardless of this constraint.Long-term, we should fix this, but unfortunately I don't have cycles to dive into fastalloc's internals at the moment, and it's (I think) a tier-3 feature. As such, this PR disables its use for now. I've filed a tracking issue in RA2 2, and referenced this in the Cranelift configuration option docs at least.
To keep from shifting all fuzzbugs / fuzzing corpii by altering the
arbitraryinterpretation, I opted to keep the enum the same in the fuzzing crate, and remapSinglePasstoBacktrackingthere. I'm happy to take the other approach and remove the option (thus invalidating all fuzzbugs) if we'd prefer that instead.