Skip to content
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

Use proper context in initClass for GDV #87847

Merged
merged 31 commits into from
Jul 26, 2023
Merged

Conversation

EgorBo
Copy link
Member

@EgorBo EgorBo commented Jun 20, 2023

Fixes #87597

Although, I am not 100% sure in it, checking CI...

@dotnet-issue-labeler dotnet-issue-labeler bot added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Jun 20, 2023
@ghost ghost assigned EgorBo Jun 20, 2023
@ghost
Copy link

ghost commented Jun 20, 2023

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

Issue Details

Fixes #87597

Although, I am not 100% sure in it, checking CI...

Author: EgorBo
Assignees: -
Labels:

area-CodeGen-coreclr

Milestone: -

@EgorBo
Copy link
Member Author

EgorBo commented Jun 22, 2023

Massive diffs are just SPMI artifacts - if initClass VM API is invoked with args it has never invoked before - it returns "DONT_INLINE" (instead of reporting a missing context) here:

return CORINFO_INITCLASS_DONT_INLINE;

@AndyAyersMS
Copy link
Member

We should try and get this fix in soon, and then make a case for back porting it to .NET 7.

@MichalStrehovsky
Copy link
Member

Basically, resolveVirtualMethod fails to resolve an interface method over Boolean (primitive/value type) type 😕

In the screenshot, the ToString of decl starts with Unboxing MethodDesc:. This means this is the alternative entrypoint of the method that will first unbox this and then call a method on the valuetype.

It looks like this API is not expecting to see these. Should RyuJIT call getUnboxedEntry on this first? Someone needs to first convert this to the sane variant. I don't have a good idea from this who should do it.

@davidwrighton
Copy link
Member

/azp list

@azure-pipelines
Copy link

CI/CD Pipelines for this repository:

@davidwrighton
Copy link
Member

/azp run runtime-coreclr crossgen2 outerloop

@azure-pipelines
Copy link

No commit pushedDate could be found for PR 87847 in repo dotnet/runtime

@davidwrighton
Copy link
Member

/azp run runtime-coreclr crossgen2 outerloop

@azure-pipelines
Copy link

No commit pushedDate could be found for PR 87847 in repo dotnet/runtime

@EgorBo
Copy link
Member Author

EgorBo commented Jul 22, 2023

/azp run runtime-coreclr outerloop, runtime-coreclr crossgen2, runtime-extra-platforms, runtime-coreclr pgostress

@azure-pipelines
Copy link

Azure Pipelines successfully started running 4 pipeline(s).

@EgorBo EgorBo marked this pull request as ready for review July 24, 2023 19:39
@EgorBo
Copy link
Member Author

EgorBo commented Jul 24, 2023

@AndyAyersMS can you please sign it off, it seems to be passing all outerloop jobs

Copy link
Member

@AndyAyersMS AndyAyersMS left a 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)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this ever NULL?

Copy link
Member Author

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;
Copy link
Member

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?

Copy link
Member Author

@EgorBo EgorBo Jul 24, 2023

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

Copy link
Member Author

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Access Violation in jithelpers with Dynamic PGO enabled
6 participants