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

Fix compFastTailCalls check. #35596

Merged
merged 1 commit into from
Apr 30, 2020

Conversation

erozenfeld
Copy link
Member

compFastTailCalls is true if COMPlus_FastTailCalls is not 0.
It was introduced in #341 to help with testing:
setting COMPlus_FastTailCalls to 0 forces all tail-prefixed
calls to be dispatched via helpers.

This fixes a subtle bug with checking compFastTailCalls:
it needs to be checked after fgInitargInfo has been called in
fgCanFastTailCall. fgInitArgInfo adds the stub address for VSD calls
and fgMorphTailCallViaHelpers then removes it.

@Dotnet-GitSync-Bot Dotnet-GitSync-Bot added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Apr 29, 2020
@erozenfeld
Copy link
Member Author

@dotnet/jit-contrib @AndyAyersMS @jakobbotsch PTAL

@erozenfeld
Copy link
Member Author

With this change all but one Pri 0 x64 checked tests pass with COMPlus_FastTailCalls set to 0. The only failing test is JIT\opt\OSR\tailrecursetry\tailrecursetry.cmd, which fails with

Assert failure(PID 20952 [0x000051d8], Thread: 18380 [0x47cc]): Assertion failed 'phiFound' in 'TailRecursionWithOsrEntryInTry:F(int,int,int,int):int' during 'SSA: insert phis' (IL size 49)

    File: F:\runtime\src\coreclr\src\jit\ssabuilder.cpp Line: 922
    Image: f:\runtime\artifacts\tests\coreclr\Windows_NT.x64.Checked\Tests\Core_Root\CoreRun.exe

That test turns on on-stack replacement. I'll open an issue for that failure once this change is in.

}
return false;
}

Copy link
Member

Choose a reason for hiding this comment

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

Can we move it even farther below and use the reportFastTailCallDecision lambda? Then it will also go through the fast tail call decisions reporting there is in debug.

Copy link
Member Author

Choose a reason for hiding this comment

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

Makes sense, done.

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.

Aside from @jakobbotsch 's feedback, looks good to me.

A few things for potential follow-up:

I think this method probably needs to be refactored -- the big chunk of code I added for checking implicit byrefs should be made into a helper, and we should do that check last, since it is potentially a bit more costly. But no need to do that now.

I wonder if we should modify how we handle implicit tail calls when this config setting is active, and have them be helper assisted as well. We probably get the same effect with this config plus tail call stress -- do you know if we've tried this?

Do we need to revisit the check in fgMakeOutgoingStructArgCopy that requires that the jit makes copies for helper tail calls? I forget where we ended up on this one.

compFastTailCalls is true if COMPlus_FastTailCalls is not 0.
It was introduced in dotnet#341 to help with testing:
setting COMPlus_FastTailCalls to 0 forces all tail-prefixed
calls to be dispatched via helpers.

This fixes a subtle bug with checking compFastTailCalls:
it needs to be checked after `fgInitargInfo` has been called in
`fgCanFastTailCall`. `fgInitArgInfo` adds the stub address for VSD calls
and `fgMorphTailCallViaHelpers` then removes it.

This change also factors out the logic for checking whether the call
has byref parameters that must be copied by the caller.
@erozenfeld
Copy link
Member Author

I think this method probably needs to be refactored -- the big chunk of code I added for checking implicit byrefs should be made into a helper, and we should do that check last, since it is potentially a bit more costly. But no need to do that now.

I went ahead and did it now.

I wonder if we should modify how we handle implicit tail calls when this config setting is active, and have them be helper assisted as well. We probably get the same effect with this config plus tail call stress -- do you know if we've tried this?

Yes, tail call stress with COMPlus_FastTailCalls set to 0 should have the same effect. I haven't tried it yet, it's on my list.

Do we need to revisit the check in fgMakeOutgoingStructArgCopy that requires that the jit makes copies for helper tail calls? I forget where we ended up on this one.

Yes, I think we can relax that check now. I'll address that separately.

@erozenfeld
Copy link
Member Author

I will make sure there are no diffs with COMPlus_FastTailCalls not set before merging this.

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.

LGTM -- thanks for the refactoring.

@erozenfeld erozenfeld closed this Apr 30, 2020
@erozenfeld erozenfeld reopened this Apr 30, 2020
@erozenfeld erozenfeld merged commit 4becc75 into dotnet:master Apr 30, 2020
@erozenfeld
Copy link
Member Author

I wonder if we should modify how we handle implicit tail calls when this config setting is active, and have them be helper assisted as well. We probably get the same effect with this config plus tail call stress -- do you know if we've tried this?

I ran Pri0 x64 checked tests with

set COMPlus_TailCallStress=1
COMPlus_FastTailCalls=0

There are no new failures in this configuration.

@ghost ghost locked as resolved and limited conversation to collaborators Dec 9, 2020
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.

5 participants