-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Various fixes for consecutive registers found with jitstressregs #84824
Various fixes for consecutive registers found with jitstressregs #84824
Conversation
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch, @kunalspathak Issue Detailsnull
|
/azp run runtime-coreclr jitstress |
/azp run runtime-coreclr jitstressregs |
Azure Pipelines successfully started running 1 pipeline(s). |
1 similar comment
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run runtime-coreclr jitstress2-jitstressregs |
Azure Pipelines successfully started running 1 pipeline(s). |
This method will track if the defs/uses are live at the same location as where the consecutive registers were allocated. If yes, it will skip the constraint imposition on it during JitStressRegs
When we have copyReg that was just restored or previously assigned to a different register, also track it as live at the location so it doesn't get allocated again for different refposition at the same location.
/azp run runtime-coreclr jitstress |
/azp run runtime-coreclr jitstress2-jitstressregs |
Azure Pipelines successfully started running 1 pipeline(s). |
1 similar comment
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run runtime-coreclr jitstressregs |
Azure Pipelines successfully started running 1 pipeline(s). |
…isters Under JitStressRegs, there are multiple ways in which consecutive registers demand cannot be met. So skip restricting the registers for `registerAssignment` of a refPosition (which are allowable candidates that can be assigned to the given refposition). Instead limit the free registers to alternate under stress mode, so we can verify the code if it can handle situation where it needs to pick from a mix of free/busy registers.
/azp run runtime-coreclr jitstress |
No pipelines are associated with this pull request. |
/azp run runtime-coreclr jitstress |
/azp run runtime-coreclr jitstress2-jitstressregs |
/azp run runtime-coreclr jitstressregs |
Azure Pipelines successfully started running 1 pipeline(s). |
2 similar comments
Azure Pipelines successfully started running 1 pipeline(s). |
Azure Pipelines successfully started running 1 pipeline(s). |
All the CI legs are passing. There is failures on x64 for which I have opened #84961. There are failures in |
They are on main as well. Opened #84966. |
@dotnet/jit-contrib @BruceForstall |
ping @BruceForstall |
Adding the links for green runs : |
@@ -1784,6 +1784,12 @@ class LinearScan : public LinearScanInterface | |||
void clearSpillCost(regNumber reg, var_types regType); | |||
void updateSpillCost(regNumber reg, Interval* interval); | |||
|
|||
FORCEINLINE void updateRegsFreeBusyState(RefPosition& refPosition, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it really necessary to use FORCEINLINE?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is hot functionality used whenever we assign copyRegs with or without consecutive registers. I didn't want to impact the TP for just extracting out this functionality in a method.
copyReg
scenario where not recorded as live at the location because of which we were reassigning it to a different variable, overwriting its value before consuming it for copy. This relates to my findings in [JitStress] VectorTableLookupExtension fails in jitstress1 #84696 (comment).FIELD_LIST
is populated. But, between that and the intrinsic node, where it is consumed, there can be any number of nodes (likeGT_CALL
) where the restored upper half vectors can be again wiped off. Make sure to insert the restores just before the use of theFIELD_LIST
node. This relates to my findings in [JitStress] VectorTableLookupExtension fails in jitstress1 #84696 (comment).isLiveAtConsecutiveRegistersLoc
and we will skip constraining the registers for such refpositions. However, to stress test the busy consecutive registers and free/busy code path, I have added a constraint on free registers that the algorithm sees under stress mode.Fixes: #84747, #84696, #84746