Stream: git-wasmtime

Topic: wasmtime / PR #12841 Cranelift: perform aggressive splitt...

Wasmtime GitHub notifications bot (Mar 25 2026 at 18:37):

cfallin opened PR #12841 from cfallin:isle-debug-build-splitting to bytecodealliance:main:

As investigated in #12821, ISLE-generated Rust code with many locals in one large function body results in unreasonably-large stack frames when rustc's optimizations (and therefore LLVM's mem2reg) are disabled. In constructor_simplify, a single function body generated from all mid-end rewrite rules, I was seeing a stack-frame size of 0x44000 bytes (272 KiB) on x86-64 (while in an opt build it is 0x1000 bytes (4 KiB)). With a recursion depth of 5 (the default limit) for rewrites of RHS-created nodes, this has the potential to overrun a 1 MiB stack; and is generally quite wasteful.

In [another branch] I attempted to make islec do manual regalloc of a sort just for multi-extractor iterators; but soon realized that the problem has to do with all locals (which become allocas in LLVM IR), not just the iterators. We could do the equivalent thing to share all locals but this would become grossly un-idiomatic for e.g. LHSes of destructuring in Rust.

Instead, this PR leverages previous work in #12303 (thanks Bongjun!) that splits function bodies in the generated Rust code from ISLE with a configurable threshold. This PR enables that feature and makes the threshold quite low in debug builds. This has the natural effect of splitting locals among many smaller stack frames, which are dynamically pushed only when matching enters a particular subtree; so stack usage more closely mirrors the actual live-set of values bound during matching.

With this change, the stack frame for the top-level constructor_simplify is < 4 KiB on x86-64 in a debug build.

Fixes #12821.

[another branch]: https://github.com/cfallin/wasmtime/tree/isle-iterator-reuse

<!--
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.html

Please ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->

Wasmtime GitHub notifications bot (Mar 25 2026 at 18:37):

cfallin requested fitzgen for a review on PR #12841.

Wasmtime GitHub notifications bot (Mar 25 2026 at 18:37):

cfallin requested wasmtime-compiler-reviewers for a review on PR #12841.

Wasmtime GitHub notifications bot (Mar 25 2026 at 18:59):

fitzgen submitted PR review:

Nice!

Wasmtime GitHub notifications bot (Mar 25 2026 at 18:59):

fitzgen added PR #12841 Cranelift: perform aggressive splitting of generated ISLE function bodies in debug builds. to the merge queue

Wasmtime GitHub notifications bot (Mar 25 2026 at 19:23):

fitzgen merged PR #12841.

Wasmtime GitHub notifications bot (Mar 25 2026 at 19:23):

fitzgen removed PR #12841 Cranelift: perform aggressive splitting of generated ISLE function bodies in debug builds. from the merge queue

Last updated: Apr 12 2026 at 23:10 UTC