-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Use proper context in initClass for GDV #87847
Conversation
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch Issue DetailsFixes #87597 Although, I am not 100% sure in it, checking CI...
|
Massive diffs are just SPMI artifacts - if
|
We should try and get this fix in soon, and then make a case for back porting it to .NET 7. |
In the screenshot, the It looks like this API is not expecting to see these. Should RyuJIT call |
/azp list |
/azp run runtime-coreclr crossgen2 outerloop |
No commit pushedDate could be found for PR 87847 in repo dotnet/runtime |
/azp run runtime-coreclr crossgen2 outerloop |
No commit pushedDate could be found for PR 87847 in repo dotnet/runtime |
/azp run runtime-coreclr outerloop, runtime-coreclr crossgen2, runtime-extra-platforms, runtime-coreclr pgostress |
Azure Pipelines successfully started running 4 pipeline(s). |
@AndyAyersMS can you please sign it off, it seems to be passing all outerloop jobs |
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.
Ok with taking this as is and addressing the comments in a follow-up.
@@ -6295,8 +6300,14 @@ void Compiler::impMarkInlineCandidate(GenTree* callNode, | |||
{ | |||
InlineResult inlineResult(this, call, nullptr, "impMarkInlineCandidate for GDV"); | |||
|
|||
CORINFO_CONTEXT_HANDLE moreExactContext = call->GetGDVCandidateInfo(candidateId)->exactContextHnd; | |||
if (moreExactContext == NULL) |
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 this ever NULL
?
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.
afair, it's null for method-profiling (delegates)
@@ -862,7 +862,7 @@ class IndirectCallTransformer | |||
|
|||
JITDUMP("Direct call [%06u] in block " FMT_BB "\n", compiler->dspTreeID(call), block->bbNum); | |||
|
|||
CORINFO_METHOD_HANDLE methodHnd = call->gtCallMethHnd; | |||
CORINFO_METHOD_HANDLE methodHnd = inlineInfo->guardedMethodHandle; |
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 think this isn't strictly necessary...?
Consider leaving as is and then asserting that the method that impDevirtualizeCall
produces is the one we expected?
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'll check with recent David's VM changes, but last time I checked this was an important part to fix asserts. Basically, call->gtCallMethHnd
is the initial base method (e.g. IFoo.DoWork), while inlineInfo->guardedMethodHandle
is the actual method we're going to inline
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.
Just checked - we still assert in both VMs for that. The problem that we pass the base MethodDesc
+ more precise generic context that belongs to the inlineInfo->guardedMethodHandle
Fixes #87597
Although, I am not 100% sure in it, checking CI...