Fix compFastTailCalls check.

[erozenfeld]

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.

[erozenfeld]

@dotnet/jit-contrib @AndyAyersMS@jakobbotsch PTAL

[erozenfeld]

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.

[jakobbotsch]

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.

[erozenfeld]

Makes sense, done.

[AndyAyersMS]

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.

[erozenfeld]

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]

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

[AndyAyersMS]

LGTM -- thanks for the refactoring.

[erozenfeld]

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.

[erozenfeld]

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.

[erozenfeld]

@dotnet/jit-contrib @AndyAyersMS@jakobbotsch PTAL

[erozenfeld]

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.

[jakobbotsch]

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.

[erozenfeld]

Makes sense, done.

[AndyAyersMS]

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.

[erozenfeld]

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]

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

[AndyAyersMS]

LGTM -- thanks for the refactoring.

[erozenfeld]

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.

[erozenfeld]

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.

[erozenfeld]

@dotnet/jit-contrib @AndyAyersMS@jakobbotsch PTAL

[erozenfeld]

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.

[jakobbotsch]

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.

[erozenfeld]

Makes sense, done.

[AndyAyersMS]

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.

[erozenfeld]

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]

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

[AndyAyersMS]

LGTM -- thanks for the refactoring.

[erozenfeld]

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.

[erozenfeld]

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.

[erozenfeld]

@dotnet/jit-contrib @AndyAyersMS@jakobbotsch PTAL

[erozenfeld]

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.

[jakobbotsch]

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.

[erozenfeld]

Makes sense, done.

[AndyAyersMS]

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.

[erozenfeld]

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]

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

[AndyAyersMS]

LGTM -- thanks for the refactoring.

[erozenfeld]

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.

[erozenfeld]

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.

[erozenfeld]

@dotnet/jit-contrib @AndyAyersMS@jakobbotsch PTAL

[erozenfeld]

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.

[jakobbotsch]

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.

[erozenfeld]

Makes sense, done.

[AndyAyersMS]

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.

[erozenfeld]

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]

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

[AndyAyersMS]

LGTM -- thanks for the refactoring.

[erozenfeld]

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.

[erozenfeld]

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.

[erozenfeld]

@dotnet/jit-contrib @AndyAyersMS@jakobbotsch PTAL

[erozenfeld]

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.

[jakobbotsch]

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.

[erozenfeld]

Makes sense, done.

[AndyAyersMS]

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.

[erozenfeld]

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]

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

[AndyAyersMS]

LGTM -- thanks for the refactoring.

[erozenfeld]

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.

[erozenfeld]

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.

[erozenfeld]

@dotnet/jit-contrib @AndyAyersMS@jakobbotsch PTAL

[erozenfeld]

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.

[jakobbotsch]

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.

[erozenfeld]

Makes sense, done.

[AndyAyersMS]

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.

[erozenfeld]

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]

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

[AndyAyersMS]

LGTM -- thanks for the refactoring.

[erozenfeld]

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.

[erozenfeld]

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.

[erozenfeld]

@dotnet/jit-contrib @AndyAyersMS@jakobbotsch PTAL

[erozenfeld]

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.

[jakobbotsch]

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.

[erozenfeld]

Makes sense, done.

[AndyAyersMS]

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.

[erozenfeld]

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]

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

[AndyAyersMS]

LGTM -- thanks for the refactoring.

[erozenfeld]

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.