-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
Generate calls to interface methods through resolve helper #112406
base: main
Are you sure you want to change the base?
Conversation
Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas |
/azp run runtime-nativeaot-outerloop |
Azure Pipelines successfully started running 1 pipeline(s). |
This reverts commit 7f879d6.
For this not to be a throughput regression, we need to figure out a clean way to implement the hack in last two commits. I ran JSON serialization with/without this PR. Having to preserve argument registers before calling the resolve helper costs us about 1% in throughput. PR-hack is the hack where we allow RyuJIT to assume argument registers are not clobbered. We better not take a GC in the slow path.
Do we have a way to do this hack cleanly that doesn't involve building a new universal transition? |
/azp run runtime-nativeaot-outerloop |
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run runtime-nativeaot-outerloop |
Azure Pipelines successfully started running 1 pipeline(s). |
342fb19
to
b370b17
Compare
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.
Copilot reviewed 3 out of 22 changed files in this pull request and generated no comments.
Files not reviewed (19)
- src/coreclr/inc/corinfo.h: Language not supported
- src/coreclr/inc/jiteeversionguid.h: Language not supported
- src/coreclr/inc/jithelpers.h: Language not supported
- src/coreclr/jit/codegencommon.cpp: Language not supported
- src/coreclr/jit/gentree.cpp: Language not supported
- src/coreclr/jit/gentree.h: Language not supported
- src/coreclr/jit/lower.cpp: Language not supported
- src/coreclr/jit/morph.cpp: Language not supported
- src/coreclr/jit/targetamd64.h: Language not supported
- src/coreclr/jit/targetarm64.h: Language not supported
- src/coreclr/nativeaot/Runtime/AsmOffsets.h: Language not supported
- src/coreclr/nativeaot/Runtime/CMakeLists.txt: Language not supported
- src/coreclr/nativeaot/Runtime/EHHelpers.cpp: Language not supported
- src/coreclr/nativeaot/Runtime/StackFrameIterator.cpp: Language not supported
- src/coreclr/nativeaot/Runtime/amd64/DispatchResolve.asm: Language not supported
- src/coreclr/nativeaot/Runtime/amd64/UniversalTransition.asm: Language not supported
- src/coreclr/nativeaot/Runtime/arm64/DispatchResolve.asm: Language not supported
- src/coreclr/nativeaot/Runtime/arm64/UniversalTransition.asm: Language not supported
- src/coreclr/nativeaot/Runtime/inc/rhbinder.h: Language not supported
Comments suppressed due to low confidence (1)
src/coreclr/tools/Common/JitInterface/CorInfoHelpFunc.cs:267
- Ensure that the new helper CORINFO_HELP_INTERFACELOOKUP_FOR_SLOT is covered by tests to verify its behavior.
CORINFO_HELP_INTERFACELOOKUP_FOR_SLOT, // Resolve a non-generic interface method from this pointer and dispatch cell
@dotnet/ilc-contrib this is ready for review @jakobbotsch who would be the best to review the JIT side? |
@@ -309,6 +309,7 @@ | |||
JITHELPER(CORINFO_HELP_JIT_REVERSE_PINVOKE_EXIT_TRACK_TRANSITIONS, JIT_ReversePInvokeExitTrackTransitions, METHOD__NIL) | |||
|
|||
JITHELPER(CORINFO_HELP_GVMLOOKUP_FOR_SLOT, NULL, METHOD__NIL) | |||
JITHELPER(CORINFO_HELP_INTERFACELOOKUP_FOR_SLOT, NULL, METHOD__NIL) |
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.
How hard would it be to add an implementation for coreclr? Currently jit-cfg is likely to be broken by this change. It would be nice to make it work without having to make the JIT side codegen different from NAOT pattern.
Alternatively I guess it would be even more ideal if we switched the testing to a CFG-enabled outerloop NAOT run now that the support is more mature... But that's probably a bit more work.
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.
I thought CoreCLR doesn't even do interface dispatch in this shape? I thought #111771 tries to bring it over, but for some very limited scenarios. Are the interface codepaths even exercised under CoreCLR?
We already have a CFG run on native AOT but only on x64. It should be easy enough to add arm64 one. But we don't have any stress modes for either GC or JIT.
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.
I am not totally sure what the difference between CID and VSD is, but from the JIT codegen standpoint it looks identical to me.
In the worst case I would be ok with guarding the transformation in lowering under a NAOT check.
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.
@jkotas if I wanted to implement a CORINFO_HELP_INTERFACELOOKUP_FOR_SLOT on CoreCLR, would I need to somehow call VirtualCallStubManager::ResolveWorker
? It's not exactly clear to me where I would find the parameters to call it so wondering if there's a better way.
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.
I have pushed a commit into this PR that shows what it may look like on win x64. It calls the slow resolve helper every time. If it is too slow for the test, it is possible to improve the perf by adding a NAOT-like fast path once David's PR #111771 goes in.
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.
I have pushed a commit into this PR that shows what it may look like on win x64
Thank you ❤️! I'll kick off a JIT-cfg run to see if the perf is acceptable. I think we'd basically only care if this more than quadruples the time it takes for the CI to run. These legs run very infrequently.
/azp list |
/azp run jit-cfg |
Azure Pipelines successfully started running 1 pipeline(s). |
Runtime changes LGTM |
/azp run jit-cfg |
Azure Pipelines successfully started running 1 pipeline(s). |
This changes interface calls when CFG is enabled to use a resolve helper instead of the stub dispatcher. I've also extended the CFG testing a bit to cover more of interface calls in the smoke test.
Before this change:
After this change: