Skip to content

Avoid trimming spill ranges into deeper loops - #272

Open
wraitii wants to merge 1 commit into
bytecodealliance:mainfrom
wraitii:trim-loop-spill
Open

wraitii wants to merge 1 commit into
bytecodealliance:mainfrom
wraitii:trim-loop-spill

Conversation

@wraitii

@wraitii wraitii commented Nov 8, 2026

Copy link
Copy Markdown

Stop spill-range trimming when it would enter a deeper loop than the split point, on either side of the split. This prevents preservation around a call outside a loop from introducing unnecessary stores and reloads inside that loop.

See #271 for details. This PR was written by GPT-6 Astra, the fix looks reasonable to me but I can't say I have a deep understanding of this codebase. It's also a heuristic, as explained in the issue.

Validation that Astra ran:

  • All regalloc2 tests pass, plus 6,799 randomized allocation checks.
  • Both versions pass 1,399 Cranelift filetests and 1,196 checker-enabled files; existing assembly snapshots are unchanged.
  • Five targeted execution checks pass on both versions.
  • Sightglass: all 29 PCA workloads, 20 samples per engine on Apple ARM64. No statistically significant compilation or execution regression detected.

Stop spill-range trimming when it would enter a deeper loop than the split point. In general, this behaves badly if the last use is inside a loop, as it requires storing to the stack within the loop.

@cfallin cfallin left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! This change looks reasonable to me. In addition to the Sightglass runs and Wasmtime+Cranelift test suites, could you do a fuzzing run with the ion fuzz harness (which generates random function bodies and runs the symbolic checker over the allocation result) on at least 8 cores for at least 24 hours? That is the standard I've held my own changes to at least (and empirically we're at the point on the bugfinding curve where we sometimes find issues say ~12-CPU-hours in or so, so this seems to be necessary).

Something like:

cargo +nightly fuzz run -s none ion -j8

Thanks!

@@ -0,0 +1,180 @@
//! Values live across a call after a loop should spill at the call, not on

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't have a test infrastructure like this intentionally -- this is a ton of boilerplate and also unnecessarily bakes in heuristic answers that may change in the future. Could you delete this test? We generally rely on perf tests to know if/when things regress, and aggressive fuzzing with the checker to know that we preserve correctness, otherwise let the heuristics do what they will.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

mh yeah in hindsight, should probably have figured that out. I'll drop the test.

@wraitii

wraitii commented Nov 9, 2026

Copy link
Copy Markdown
Author

Thanks for the read through! I will see what I can do about that, as to clarify I'm doing this as a hobby project on my personal computer, so it'll probably take me a bit more time :D

I'll also rerun the other tests especially SightGlass over more of the suite & at higher samples when I get to it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants