Jakob Meier (jakmeier) (May 01 2026 at 13:06): Jakob Meier (jakmeier) (May 01 2026 at 13:06):Hello!
Can I ask what the concerns for RegallocAlgorithm::SinglePass production readiness are?
We noticed this PR #11864 mentioning fuzzer issues and adding the doc comment about not being production ready.
I'm currently working with Near Protocol and they are very much interested in using it in production.
Alex Crichton (May 01 2026 at 14:25):We've historically considered this a "tier 2" feature insofar as it hasn't necessarily survived fuzzing for extended periods of time. That specific fuzz-bug is actually closed so we should probably turn fuzzing back on, though.
Overall it's not as battle hardened as the default regalloc2 allocator, but community maintenance of it so far has kept up with issues.
Jakob Meier (jakmeier) (May 01 2026 at 15:18):Thank you for the clear reply!
I see you've already sent a PR to enable fuzzing again, that's great to see. It will be a few months before we would use it anyway, I will monitor the stability of this in the meantime.
Linear time regalloc is quite important to us, as our threat-model requires to work well even with maliciously crafted WASMs. With the backtracking regalloc, we are able to craft cases of ~12MB sized valid WASM files that take wasmtime ~20s to compile with memory peaks of ~12GB (RSS), even withOptLevel::None. Using the single pass regalloc brings it down to 0.15s / 0.9 GB . (I can share more details here on in private if that's unexpected / interesting to you.)
Chris Fallin (May 01 2026 at 15:39):@Jakob Meier (jakmeier) FWIW, if you need linear-time compilation, you almost certainly should be using Winch, not Cranelift: there are other parts of Cranelift that will go superlinear too (we work our hardest to avoid blowups, but that is absolutely a fundamental tradeoff for any optimizing compiler)
Chris Fallin (May 01 2026 at 15:40):(and it's not too surprising that you can craft Wasm with e.g. very gnarly interference patterns that will lead to worst-case backtracking and minimal bundle splits in regalloc...)
Jakob Meier (jakmeier) (May 01 2026 at 16:04):it's not too surprising that you can craft Wasm with e.g. very gnarly interference patterns that will lead to worst-case backtracking and minimal bundle splits in regalloc...
Yeah, that's what I expected, thanks for confirming.
Yes, Winch would make more sense to us, indeed. Would you say that is fully production ready today? @Chris Fallin
Chris Fallin (May 01 2026 at 16:06):It depends on what you need. It is tier-1 on x86-64, not on other platforms (and the only other platform with basic support is aarch64). It is missing a number of key Wasm features, like exceptions, GC, tail calls. But it is known to be used in production (on x86) and so it's probably a safe bet if you're running Wasm modules that don't use those features
Jakob Meier (jakmeier) (May 01 2026 at 16:08):x86-64 would be good enough for production, aarch64 we only use for development on macs
Jakob Meier (jakmeier) (May 01 2026 at 16:10):Other than that concern, our problem with Winch is that older wasmtime versions still miss features like reftypes. We were able to upstream what we need(#12940, #12939). But we are stuck with Rust 1.86 for our first release with Wasmtime, which I believe means we have to use an older version of wasmtime for that. So we are kind of trying to make it work with Cranelift at least for one release cycle.
Saúl Cabrera (May 01 2026 at 16:45):@Jakob Meier (jakmeier) regarding missing features/parity with aarch64, happy to discuss if there's anything specific missing for your use-case that is currently not tracked by the open issues. Also, regarding performance (either compilation or runtime), I'd be curious to see any results if you have them and if you are willing to share. I think there are some low-hanging fruit in these areas that could be tackled if needed.
Jakob Meier (jakmeier) (May 01 2026 at 16:56):@Saúl Cabrera I assume you mean for Winch? I don't have that data right now but there's a good chance I will come back to you over the next weeks :)
Last updated: May 03 2026 at 22:13 UTC