cranelift: Remove the virtual sp offset from all backends #8631
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
After the changes required to support tail calls, the general frame layout in cranelift always includes a stack allocation that's large enough to hold all outgoing args/return values. An effect of this change is that the only place that the virtual SP offset (the offset from the current value of SP to the nominal SP) was meaningfully changed was in the function prologue, where it was always updated to include the size of the outgoing argument area. As the only other place that the virtual SP offset was modified was in the handling for call instructions to functions that used the tail-call abi, the need for the virtual SP offset is no longer obvious.
This PR removes the virtual SP offset from all backends, and instead maintains the invariant that SP always points to the end of the stack frame, right after the outgoing arguments area. This does require the call pseudo-instruction to decrement SP after a call to a tail-call function, as those free their incoming argument area, but I believe this change to be a benefit as we now no longer directly manipulate SP outside of the function prologue and epilogue.
Looking forward a bit, another benefit of this change is that it better sets us up to handle compiling without frame pointers: as SP is now a consistent base that we can address anything in the frame from, we're no longer reliant on FP to address some parts of the frame.