Do not set pre-decided consecutive registers as busy (again) #85566
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.
In #84824, I started marking the previous register assigned during
copyReg
as live. However, the previous register could be part of the consecutive registers that we are about to assign and marking it "live at this location" will make it unavailable to be assigned to the relevant subsequentRefPosition
. Start tracking the consecutive refpositions in use and do not mark such refpositions as live. Alternatively, I could delay this decision until the assignment of the particular Refposition, however, at that point we want to make sure that we are not randomly unmarking a register that was marked as "live" and hide any other unseen problem.Also fixed a AV that was hitting for
JitDump
because recently we also started doingcopyReg
forupperVectorRestore
and when we print the interval name, we hit AV becauseinterval->relatedInterval
is set tonullptr
during register assignment.Fixes: #85426