JIT: fix overly aggressive type propagation from returns

[AndyAyersMS]

For quite a while now the jit has been propagating return types from
callees to the return spill temp. However this is only safe when the
callee has a single return site (or all return sites return the same
type).

Because return spill temps often end up getting assigned to still more
temps we haven't seen this overly aggressive type propgagation lead to
bugs, but now that we're tracking single def temps and doing more type
propagation during the late devirtualization callback, the fact that
these types are wrong has been exposed and can lead to incorrect
devirtualization.

The fix is to only consider the return spill temp as single def if the
callee has a single return site, and to check that the return spill temp
is single def before trying to propagate the type.

Fixes #21295.

[AndyAyersMS]

@briansull PTAL
cc @dotnet/jit-contrib

A handful diffs from PMI... these may not have lead to observable bugs; it depends on which type was actually returned by the callee.

This bug was exposed in JitStress=2 via random inlining. Methods with multiple returns tend not to get inlined by default, but the random inliner (intentionally) doesn't play by the normal rules.

PMI Diffs for System.Private.CoreLib.dll, framework assemblies for x64 default jit
Summary:
(Lower is better)
Total bytes of diff: 61 (0.00% of base)
    diff is a regression.
Top file regressions by size (bytes):
          32 : System.Net.Sockets.dasm (0.02% of base)
          25 : System.Private.CoreLib.dasm (0.00% of base)
           4 : System.Net.Security.dasm (0.00% of base)
3 total files with size differences (0 improved, 3 regressed), 126 unchanged.
Top method regressions by size (bytes):
          32 ( 9.94% of base) : System.Net.Sockets.dasm - Socket:SendFileInternal(ref,ref,ref,int):this
          18 ( 7.76% of base) : System.Private.CoreLib.dasm - RuntimeConstructorInfo:get_InvocationFlags():int:this
           4 ( 0.61% of base) : System.Net.Security.dasm - SecureChannel:NextMessage(ref,int,int):ref:this
           3 ( 0.90% of base) : System.Private.CoreLib.dasm - RuntimePropertyInfo:SetValue(ref,ref,int,ref,ref,ref):this
           3 ( 4.92% of base) : System.Private.CoreLib.dasm - ConstructorBuilder:get_CallingConvention():int:this
Top method improvements by size (bytes):
          -1 (-0.53% of base) : System.Private.CoreLib.dasm - RuntimePropertyInfo:GetValue(ref,int,ref,ref,ref):ref:this
Top method regressions by size (percentage):
          32 ( 9.94% of base) : System.Net.Sockets.dasm - Socket:SendFileInternal(ref,ref,ref,int):this
          18 ( 7.76% of base) : System.Private.CoreLib.dasm - RuntimeConstructorInfo:get_InvocationFlags():int:this
           3 ( 4.92% of base) : System.Private.CoreLib.dasm - ConstructorBuilder:get_CallingConvention():int:this
           2 ( 2.86% of base) : System.Private.CoreLib.dasm - RuntimeConstructorInfo:get_ContainsGenericParameters():bool:this
           3 ( 0.90% of base) : System.Private.CoreLib.dasm - RuntimePropertyInfo:SetValue(ref,ref,int,ref,ref,ref):this
Top method improvements by size (percentage):
          -1 (-0.53% of base) : System.Private.CoreLib.dasm - RuntimePropertyInfo:GetValue(ref,int,ref,ref,ref):ref:this
7 total methods with size differences (1 improved, 6 regressed), 191116 unchanged.

@dotnet-bot test Windows_NT x64 Cross Checked corefx_jitstress2 Build and Test
@dotnet-bot test Windows_NT x64_arm64_altjit Checked corefx_jitstress2

[AndyAyersMS]

@dotnet-bot test Windows_NT x86_arm_altjit Checked corefx_jitstress2

[AaronRobinsonMSFT]

@AndyAyersMS This is failing because of a new test. I am checking in something that should fx the issue, but if it doesn;t I will simply disable the test.

[AndyAyersMS]

Ok, thanks...

[AndyAyersMS]

@dotnet-bot test Windows_NT x64 Checked corefx_jitstress2

[AaronRobinsonMSFT]

See #21315

@dotnet-bot test Windows_NT arm Cross Debug Innerloop Build please
@dotnet-bot test Windows_NT x64 full_opt ryujit CoreCLR Perf Tests Correctness please
@dotnet-bot test Windows_NT x86 Checked Innerloop Build and Test please
@dotnet-bot test Windows_NT x86 full_opt ryujit CoreCLR Perf Tests Correctness please

[AndyAyersMS]

I can't repro the trace listener failures in the x64 checked corefx jitstress 2 and other runs. Wonder if there is some artifact where if the test run crosses over a month-end boundary they might fail. Errors are of the form

Assert.Equal() Failure\r\n ↓ (pos 1)\r\nExpected: 12-DD-YY\r\nActual: 11-DD-YY\r\n ↑ (pos 1)

So am going to retry these.

@dotnet-bot test Windows_NT x64 Checked corefx_jitstress2
@dotnet-bot test Windows_NT x64_arm64_altjit Checked corefx_jitstress2
@dotnet-bot test Windows_NT x86_arm_altjit Checked corefx_jitstress2

There also appear to be some baseline failures in the CoreFX jitstress2 runs, but only a handful.

[AndyAyersMS]

Think the remaining jitstress 2 failures are unrelated.

[briansull]

Looks Good