-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
JIT: revise approach for x64 OSR epilogs #65609
Conversation
Rework x64 OSR so OSR methods have standard epilogs. Details in attached doc.
Tagging subscribers to this area: @JulieLeeMSFT Issue DetailsRework x64 OSR so OSR methods have standard epilogs. Details in attached doc.
|
@BruceForstall PTAL cc @dotnet/jit-contrib Should see diffs in x64 asp.net for Tier0 + patchpoint and OSR methods, but not any other collection. |
SysV failing because |
Diffs are as expected. The bigger regressions are in Tier0 methods with patchpoints, because the enlarged callee save area leads to larger offsets to locals.
|
Going to run some extra legs: jit-experimental and libraries pgo. Neither of them is currently clean so will have to interpret the results. For jit-experimental the only failures are on arm64. Since this change is x64 only, we should see just those failures. In current libraries pgo we see failures with OSR enabled:
which are hallmarks of bad epilog unwinds. Those should be gone with this fix. |
/azp run runtime-jit-experimental |
Azure Pipelines successfully started running 1 pipeline(s). |
Looks like the changes are causing issues for some OSR cases on arm64. Will investigate. Also, EH tests on Linux x64 not happy. |
for (regNumber reg = REG_INT_LAST; tier0IntCalleeSaves != RBM_NONE; reg = REG_PREV(reg)) | ||
{ | ||
regMaskTP regBit = genRegMask(reg); | ||
|
||
if ((regBit & tier0IntCalleeSaves) != 0) | ||
{ | ||
compiler->unwindPush(reg); | ||
} | ||
tier0IntCalleeSaves &= ~regBit; | ||
} |
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.
Maybe consider using genFindLowestReg
here? Took me a bit to understand this loop.
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 working backwards through the "preferred pop order" for registers. It needs to match what we do in epilog gen (where we walk from REG_INT_FIRST
via REG_NEXT
.
I don't know if that corresponds to numeric order.
I also don't know if the order actually matters for x64 (as long as prolog, epilog, and unwind agree) -- I think the ordering requirement may be an x86-ism where the code manager does a lot of inspection of the jitted codegen rather than relying on unwind. In particular for x64 OSR there can now be two disjoint ranges of pushes/pops; each range will be in the proper order but overall the registers may be handled out of order.
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.
Ah, I see. That makes sense.
Hopefully that's the last of the missing bits of code. |
/azp run runtime-jit-experimental |
Azure Pipelines successfully started running 1 pipeline(s). |
With the most recent fix, I expect jit-experimental to be clean. We'll see. |
/azp run runtime-jit-experimental |
Azure Pipelines successfully started running 1 pipeline(s). |
Almost. One pre-existing failure not yet fixed.
|
Rework x64 OSR so OSR methods have standard epilogs.
Details in attached doc.