Repository navigation
Conversation
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
left a comment
There was a problem hiding this comment.
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 | |||
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
mh yeah in hindsight, should probably have figured that out. I'll drop the test.
|
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. |
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: