Test failure: System.Runtime.CompilerServices.UnsafeTests.BitCast

[v-wenyuxu]

Failed in: runtime-coreclr libraries-jitstress-random 20240413.1

Failed tests:

net9.0-windows-Release-x86-jitstress_random_2-Windows.10.Amd64.Open
    - System.Runtime.CompilerServices.UnsafeTests.BitCast

Error message:

 Assert.Equal() Failure: Values differ
Expected: S4 { a = 255, b = 0, c = 0, d = 0 }
Actual:   S4 { a = 255, b = 0, c = 173, d = 11 }

Stack trace:

   at System.Runtime.CompilerServices.UnsafeTests.BitCast() in /_/src/libraries/System.Runtime/tests/System.Runtime.CompilerServices.Unsafe.Tests/UnsafeTests.cs:line 1241
   at System.RuntimeMethodHandle.InvokeMethod(Object target, Void** arguments, Signature sig, Boolean isConstructor)
   at System.Reflection.MethodBaseInvoker.InterpretedInvoke_Method(Object obj, IntPtr* args) in /_/src/coreclr/System.Private.CoreLib/src/System/Reflection/MethodBaseInvoker.CoreCLR.cs:line 36
   at System.Reflection.MethodBaseInvoker.InvokeWithNoArgs(Object obj, BindingFlags invokeAttr) in /_/src/libraries/System.Private.CoreLib/src/System/Reflection/MethodBaseInvoker.cs:line 57

[dotnet-policy-service]

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

[amanasifkhalid]

cc @dotnet/jit-contrib

[jakobbotsch]

The issue repros with DOTNET_JitStressModeNames=STRESS_OPT_REPEAT and TC disabled. It no longer repros with the recent test change in 617f81f, but it repros with UnsafeTests.cs on the commit before that.

[jakobbotsch]

Does not repro with DOTNET_JitDoCopyProp=0.

[jakobbotsch]

Copy prop uses the following stores:

***** BB02 [0000]
STMT00169 ( INL32 @ 0x000[E-] ... ??? ) <- INLRT @ ???
N002 (  1,  4) [000650] DA---------                         ▌  STORE_LCL_VAR ubyte  V160 tmp150      d:2 $VN.Void
N001 (  1,  4) [000648] -----------                         └──▌  CNS_INT   int    255 $31e
...
N002 (  6,  8) [001624] DA---------                         ├──▌  STORE_LCL_VAR ubyte  V155 tmp145      d:2 $VN.Void
N001 (  1,  4) [001913] -----------                         │  └──▌  CNS_INT   int    255 $31e

to perform the following copy propagation:

VN based copy assertion for [000140] V155 $31e by [000650] V160 $31e.
N001 (  9,  8) [000140] -----------                         ▌  LCL_FLD   struct<System.Runtime.CompilerServices.S4, 4> V155 tmp145      u:2[+0] <l:$120, c:$121>
copy propagated to:
N001 (  9,  8) [000140] -----------                         ▌  LCL_FLD   struct<System.Runtime.CompilerServices.S4, 4> V160 tmp150      u:2[+0] <l:$120, c:$121>

[jakobbotsch]

V155 is the first field of a promoted S2 local, so it's already weird that we have a S4 LCL_FLD use of it. That oddity happens in iteration 1 of copy prop:

VN based copy assertion for [000140] V20 $31a by [001624] V155 $31a.
N001 (  9,  8) [000140] -----------                         ▌  LCL_FLD   struct<System.Runtime.CompilerServices.S4, 4> V20 tmp10        u:2[+0] (last use) $640
copy propagated to:
N001 (  9,  8) [000140] -----------                         ▌  LCL_FLD   struct<System.Runtime.CompilerServices.S4, 4> V155 tmp145      u:2[+0] (last use) $640

During iteration 1 of copy prop we see IR like

***** BB02 [0000]
STMT00016 ( ??? ... 0x0E1 )
N005 ( 14, 12) [001627] -A---------                         ▌  COMMA     void   $VN.Void
N002 (  7,  6) [001624] DA---------                         ├──▌  STORE_LCL_VAR ubyte  V155 tmp145      d:2 $VN.Void
N001 (  2,  2) [001623] -----------                         │  └──▌  LCL_VAR   ubyte  V160 tmp150      u:2 $31a
N004 (  7,  6) [001626] DA---------                         └──▌  STORE_LCL_VAR ubyte  V156 tmp146      d:2 $VN.Void
N003 (  2,  2) [001625] -----------                            └──▌  LCL_VAR   ubyte  V161 tmp151      u:2 $40

...

***** BB02 [0000]
STMT00033 ( 0x165[E-] ... ??? )
N002 (  5,  4) [000138] DA---------                         ▌  STORE_LCL_VAR int    V20 tmp10        d:2 $VN.Void
N001 (  1,  1) [000137] -----------                         └──▌  LCL_VAR   int    V00 loc0         u:2 $31a

***** BB02 [0000]
STMT00206 ( ??? ... ??? )
N002 (  9,  8) [000787] DA--G------                         ▌  STORE_LCL_VAR struct<System.Runtime.CompilerServices.S4, 4> V77 tmp67        d:2 $VN.Void
N001 (  9,  8) [000140] -----------                         └──▌  LCL_FLD   struct<System.Runtime.CompilerServices.S4, 4> V20 tmp10        u:2[+0] (last use) $640

and do the following copy prop:

***** BB02 [0000]
STMT00206 ( ??? ... ??? )
N002 (  9,  8) [000787] DA--G------                         ▌  STORE_LCL_VAR struct<System.Runtime.CompilerServices.S4, 4> V77 tmp67        d:2 $VN.Void
N001 (  9,  8) [000140] -----------                         └──▌  LCL_FLD   struct<System.Runtime.CompilerServices.S4, 4> V155 tmp145      u:2[+0] (last use) $640

[jakobbotsch]

@SingleAccretion Any thoughts on this issue? IIRC you did some work enabling the LCL_FLD copy prop case. We don't do any type checks in copy prop for LCL_FLD, and we use the VN of the SSA def of the local instead of from the tree which seems odd to me.

JIT dump:
out_dump.txt

[SingleAccretion]

I will look at the dump deeper in the evening, but from the bits so far it looks like the old "NOL locals are not modeled correctly in VN" issue to me.

The copy prop type check that is done for LCL_VAR is a quirk which works around the VN issue. A form of it could probably be done for local fields too.

VN of the SSA def of the local instead of from the tree which seems odd to me.

The intent is you only need the value produced (local<type>[field offset]) to be the same to propagate, which is deduced from local1 == local2. In fact, an even more precise check would be to use physical selection here, so that propagation is possible even when some other pats of the local are different from the field being loaded.