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

Change gtGetThisArg not to return nullptr. #44398

Merged
merged 3 commits into from
Nov 19, 2020

Conversation

sandreenko
Copy link
Contributor

@sandreenko sandreenko commented Nov 9, 2020

bb0c5dc: Don't wrap string literal const as nop for CoreRT.

It was probably an old workaround for another Jit bug, it is most likely fixed by now.

2ae10db1383: Change gtGetThisArg not to return nullptr.

There was only 1 case where a null return was tolerated - for a tail call marked as virtual in optAssertionGen.
Check this case before we call gtGetThisArg.

Fixes dotnet/runtimelab#298

@sandreenko sandreenko added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Nov 9, 2020
if ((tree->gtFlags & GTF_CALL_NULLCHECK) || tree->AsCall()->IsVirtual())
// Ignore tail calls because they have 'this` pointer in the regular arg list and an implicit null check.
GenTreeCall* const call = tree->AsCall();
if (call->NeedsNullCheck() || (call->IsVirtual() && !call->IsTailCall()))
Copy link
Contributor Author

Choose a reason for hiding this comment

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

In fgMorphTailCallViaJitHelper we clear NeedsNullCheck, should not we also clear IsVirtual?
Then this condition will be just if (call->NeedsNullCheck() || call->IsVirtual())

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@jakobbotsch could you please advise me here?

Copy link
Member

Choose a reason for hiding this comment

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

Sorry I don't know. fgMorphTailCallViaJitHelper is the old (from before #341) tailcall mechanism used only on x86. This mechanism might be used directly for virtual calls (or VSDs), but I don't remember how the address is computed in those cases.

@sandreenko
Copy link
Contributor Author

PTAL @dotnet/jit-contrib

@sandreenko
Copy link
Contributor Author

/azp run runtime-coreclr outerloop

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@@ -7783,6 +7783,12 @@ GenTree* Compiler::fgMorphTailCallViaHelpers(GenTreeCall* call, CORINFO_TAILCALL
call->gtFlags &= ~GTF_CALL_VIRT_STUB;
Copy link
Contributor Author

Choose a reason for hiding this comment

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

We do it for stub and in my understanding for vtable we should do the same, let's see what ci thinks.

Copy link
Member

Choose a reason for hiding this comment

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

This is fgMorphTailCallViaHelpers which is for the new mechanism. Indeed those turn into normal direct calls always.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

it looks like I will need the same fix for fgMorphTailCallViaJitHelper: sandreenko@53cea4e , but I want to see if our ci catches it.

Copy link
Member

Choose a reason for hiding this comment

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

It looks like we remove all virtual kinds below:

// This is now a direct call to the store args stub and not a tailcall.
call->gtCallType = CT_USER_FUNC;
call->gtCallMethHnd = help.hStoreArgs;
call->gtFlags &= ~GTF_CALL_VIRT_KIND_MASK;
call->gtCallMoreFlags &= ~(GTF_CALL_M_TAILCALL | GTF_CALL_M_DELEGATE_INV | GTF_CALL_M_WRAPPER_DELEGATE_INV);

I guess this line is not required but doesn't hurt since this is where we remove the arg for virtual stubs.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I see, thank you. I removed changes in fgMorphTailCallViaHelpers and fixed fgMorphTailCallViaJitHelper in the same way.

It was probably an old workaround for another Jit bug, it is most likely fixed by now.
@sandreenko sandreenko changed the title Fix CoreRT const string handling. Change gtGetThisArg not to return nullptr. Nov 10, 2020
Sergey Andreenko added 2 commits November 10, 2020 10:58
There was only 1 case where a null return was tolerated - for a tail call in `optAssertionGen` marked as virtual.
However, a transformed tail call is never a virtual, fix `fgMorphTailCallViaJitHelper` to unset virtual flag.
@sandreenko
Copy link
Contributor Author

/azp run runtime-coreclr outerloop

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@@ -8435,6 +8435,10 @@ void Compiler::fgMorphTailCallViaJitHelper(GenTreeCall* call)
thisPtr = objp;
}

// TODO-Cleanup: we leave it as a virtual stub call to
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I made a try to clear GTF_CALL_VIRT_KIND_MASK here but it caused failures because logic in LowerCall depends on this flag to be set in some cases, so I reverted that change.

It would be nice to clear it and fix the failures but it is out of the scope of this bug fix for CoreRT.

@sandreenko
Copy link
Contributor Author

ping @dotnet/jit-contrib

@sandreenko
Copy link
Contributor Author

Thanks @BruceForstall for the review!

@sandreenko sandreenko merged commit 044ee8c into dotnet:master Nov 19, 2020
@ghost ghost locked as resolved and limited conversation to collaborators Dec 19, 2020
@sandreenko sandreenko deleted the fixCoreRTConstStr branch May 17, 2021 07:50
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
3 participants