DNM: X86: fix frame offset calculation with mandatory tail calls #3121
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
If there's a region of the stack reserved for potential tail call arguments (only the case when we guarantee tail calls will be honoured), this is right next to the incoming stored return address, not necessarily next to the callee-saved area, so combining the two into a single figure leads to incorrect offsets in some edge cases. This keeps the two concepts split and (hopefully) updates all users of getCalleeSavedFrameSize that need it. The notable exceptions are the stack-realignment code in emitEpilogue (~line 2117) which is where the bug came from, and Windows-ABI functions, because they don't guarantee tail calls so it should always be zero there. Similarly, the code in getFrameIndexReference that dealt with this delta wasn't present on the realigned stack branch so I refactored it so that wasn't possible any more. rdar://80786596
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
If there's a region of the stack reserved for potential tail call
arguments (only the case when we guarantee tail calls will be honoured),
this is right next to the incoming stored return address, not
necessarily next to the callee-saved area, so combining the two into a
single figure leads to incorrect offsets in some edge cases.
This keeps the two concepts split and (hopefully) updates all users of
getCalleeSavedFrameSize that need it. The notable exceptions are the
stack-realignment code in emitEpilogue (~line 2117) which is where the
bug came from, and Windows-ABI functions, because they don't guarantee
tail calls so it should always be zero there.
Similarly, the code in getFrameIndexReference that dealt with this delta
wasn't present on the realigned stack branch so I refactored it so that
wasn't possible any more.
based on https://reviews.llvm.org/D106444 with the notable change that needsStackRealignment is used instead of hasStackRealignment (which does not exist yet).
rdar://80786596