Deal with input register aliasing. #1473
Open
Conversation
This file contains 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
vext01
reviewed
Nov 21, 2024
| let op1 = m.push_and_make_operand(ti_inst.clone().into()).unwrap(); | ||
| let op2 = m.push_and_make_operand(ti_inst.into()).unwrap(); | ||
|
|
||
| // Then a use of those two variable simealtaneously will make a debug_assertion in the |
There was a problem hiding this comment.
Probably need to revise this comment, since we've fixed the assertion failure.
|
Please squash, |
Currently our register allocator assumes that SSA variables can't alias. This is true for the parts under our control -- but isn't true of the inputs to a trace! For example both `%0` and `%1` might come from `RAX`. This caused a panic in the register allocator. I'd noted the problem in ykjit#1449 but thought it happened rarely. Edd noticed that it happens in other, more common situations (including as a result of common subexpression elimination), including in a yklua benchmark, and created a test for it. This commit is a "quick fix" (it's not pretty, or efficient): when we spot aliasing, we spill aliased variables onto the stack, implicitly dealiasing them. In other words, we avoid having to think about aliasing in the main bulk of the register allocator at the expense of having to spill (and potentially unspill) values unnecessarily. Co-authored-by: Edd Barrett <[email protected]>
ltratt
force-pushed
the
spill_to_dealias
branch
from
7d45fa7
to
d8afaee
Compare
|
Squashed. |
github-merge-queue
bot
removed this pull request from the merge queue due to failed status checks
|
@ptersilie I think this might be a preexisting bug, and it might be worth trying again. If not, @vext01 thinks he's seen this bug before. |
github-merge-queue
bot
removed this pull request from the merge queue due to failed status checks
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.
NB: do not merge until Edd has confirmed this works!
Currently our register allocator assumes that SSA variables can't alias. This is true for the parts under our control -- but isn't true of the inputs to a trace! For example both
%0and%1might come fromRAX. This caused a panic in the register allocator.I'd noted the problem in #1449 but thought it happened rarely. Edd noticed that it happens in other, more common situations (including as a result of common subexpression elimination), including in a yklua benchmark, and created a test for it.
This commit is a "quick fix" (it's not pretty, or efficient): when we spot aliasing, we spill aliased variables onto the stack, implicitly dealiasing them. In other words, we avoid having to think about aliasing in the main bulk of the register allocator at the expense of having to spill (and potentially unspill) values unnecessarily.