Wasmtime GitHub notifications bot (Apr 08 2025 at 22:09): Wasmtime GitHub notifications bot (Apr 08 2025 at 22:09):cfallin opened PR #10554 from cfallin:fastalloc-not-compatible-with-exceptions to bytecodealliance:main:
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.[1]: https://oss-fuzz.com/testcase-detail/5433312476987392
[2]: https://github.com/bytecodealliance/regalloc2/issues/217<!--
Please make sure you include the following information:
If this work has been discussed elsewhere, please include a link to that
conversation. If it was discussed in an issue, just mention "issue #...".Explain why this change is needed. If the details are in an issue already,
this can be brief.Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.htmlPlease ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->
Wasmtime GitHub notifications bot (Apr 08 2025 at 22:09):cfallin requested alexcrichton for a review on PR #10554.
Wasmtime GitHub notifications bot (Apr 08 2025 at 22:09):cfallin requested wasmtime-fuzz-reviewers for a review on PR #10554.
Wasmtime GitHub notifications bot (Apr 08 2025 at 22:09):cfallin requested fitzgen for a review on PR #10554.
Wasmtime GitHub notifications bot (Apr 08 2025 at 22:09):cfallin requested wasmtime-compiler-reviewers for a review on PR #10554.
Wasmtime GitHub notifications bot (Apr 08 2025 at 22:09):cfallin requested wasmtime-core-reviewers for a review on PR #10554.
Wasmtime GitHub notifications bot (Apr 08 2025 at 22:28):fitzgen submitted PR review.
Wasmtime GitHub notifications bot (Apr 08 2025 at 22:45):cfallin updated PR #10554.
Wasmtime GitHub notifications bot (Apr 08 2025 at 22:45):cfallin has enabled auto merge for PR #10554.
Wasmtime GitHub notifications bot (Apr 09 2025 at 00:01):cfallin updated PR #10554.
Wasmtime GitHub notifications bot (Apr 09 2025 at 00:01):cfallin has enabled auto merge for PR #10554.
Wasmtime GitHub notifications bot (Apr 09 2025 at 00:35):cfallin merged PR #10554.
Wasmtime GitHub notifications bot (Jul 20 2025 at 16:12):Robbepop commented on PR #10554:
@cfallin are there plans to re-introduce
Singlepassregister allocator back into Wasmtime? I am using Wasmtime in differential fuzzing in Wasmi and was using this register allocator due to very annoying time-out issues during fuzzing.
Wasmtime GitHub notifications bot (Jul 20 2025 at 20:13):cfallin commented on PR #10554:
@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!
Last updated: Dec 06 2025 at 06:05 UTC