JIT: libraries jitstress Assertion failed 'doesVNMatch' during 'Assertion prop'

[AndyAyersMS]

x86 libraries jitstress

https://dev.azure.com/dnceng-public/public/_build/results?buildId=867933&view=ms.vss-test-web.build-test-results-tab

"C:\h\w\A3450896\p\dotnet.exe" exec --runtimeconfig System.Collections.Immutable.Tests.runtimeconfig.json --depsfile System.Collections.Immutable.Tests.deps.json xunit.console.dll System.Collections.Immutable.Tests.dll -xml testResults.xml -nologo -nocolor -notrait category=IgnoreForCI -notrait category=OuterLoop -notrait category=failing  
  Discovering: System.Collections.Immutable.Tests (method display = ClassAndMethod, method display options = None)
  Discovered:  System.Collections.Immutable.Tests (found 4292 of 4397 test cases)
  Starting:    System.Collections.Immutable.Tests (parallel test collections = on [4 threads], stop on fail = off)

DOTNET_JitStress=1
DOTNET_TieredCompilation=0

Assert failure(PID 4116 [0x00001014], Thread: 9356 [0x248c]): Assertion failed 'doesVNMatch' in 'System.Collections.Immutable.Tests.ImmutableArrayTest+<ChangeType>d__192`1[int]:MoveNext():ubyte:this' during 'Assertion prop' (IL size 362; hash 0x08aa2d36; FullOpts)

    File: D:\a\_work\1\s\src\coreclr\jit\assertionprop.cpp:1486
    Image: C:\h\w\A3450896\p\dotnet.exe

Known Issue Error Message

Fill the error message using step by step known issues guidance.

{
  "ErrorMessage": "Assertion failed 'doesVNMatch'",
  "ErrorPattern": "",
  "BuildRetry": false,
  "ExcludeConsoleLog": false
}

Known issue validation

Build: 🔎 https://dev.azure.com/dnceng-public/public/_build/results?buildId=867933
Error message validated: [Assertion failed 'doesVNMatch']
Result validation: ✅ Known issue matched with the provided build.
Validation performed at: 11/14/2024 12:58:45 PM UTC

Report

Build	Definition	Test	Pull Request
875331	dotnet/runtime	System.Collections.Immutable.Tests.WorkItemExecution	#109987
873656	dotnet/runtime	System.Collections.Immutable.Tests.WorkItemExecution	#106557
873420	dotnet/runtime	System.Collections.Immutable.Tests.WorkItemExecution	#109826
873272	dotnet/runtime	System.Collections.Immutable.Tests.WorkItemExecution	#109957
872587	dotnet/runtime	System.Collections.Immutable.Tests.WorkItemExecution	#109808
871840	dotnet/runtime	System.Collections.Immutable.Tests.WorkItemExecution	#109719
871630	dotnet/runtime	System.Collections.Immutable.Tests.WorkItemExecution	#109861
871309	dotnet/runtime	System.Collections.Immutable.Tests.WorkItemExecution	#109804
871150	dotnet/runtime	System.Collections.Immutable.Tests.WorkItemExecution
871091	dotnet/runtime	System.Collections.Immutable.Tests.WorkItemExecution	#109873
871071	dotnet/runtime	System.Collections.Immutable.Tests.WorkItemExecution	#109835
870154	dotnet/runtime	System.Collections.Immutable.Tests.WorkItemExecution	#109503
869691	dotnet/runtime	System.Collections.Immutable.Tests.WorkItemExecution	#109418
867933	dotnet/runtime	System.Collections.Immutable.Tests.WorkItemExecution	#109714

Summary

24-Hour Hit Count	7-Day Hit Count	1-Month Count
0	11	14

[dotnet-policy-service]

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

[AndyAyersMS]

@jakobbotsch possibly from the CSE/SSA change?

[jakobbotsch]

Seems likely, I'll take a look

[jakobbotsch]

CSEs are keyed by liberal VNs which guarantees that all defs and uses for a single CSE candidate have the same liberal VN. The same is not true for their conservative VNs, however -- each def/use may have a potentially unique conservative VN. However, when VN creates a new LCL_VAR, the VN it uses is just a random one from one of the other candidates -- it does not necessarily match the conservative VN that the reaching def has.

The fix will probably be to have the SSA inserter update the VN so that it matches the actual reaching definition.

[jakobbotsch]

CSEs are keyed by liberal VNs which guarantees that all defs and uses for a single CSE candidate have the same liberal VN. The same is not true for their conservative VNs, however -- each def/use may have a potentially unique conservative VN. However, when VN creates a new LCL_VAR, the VN it uses is just a random one from one of the other candidates -- it does not necessarily match the conservative VN that the reaching def has.

The fix will probably be to have the SSA inserter update the VN so that it matches the actual reaching definition.

Things don't look quite that simple as CSE does a bit of post processing over the conservative VNs. Will probably have to refactor things in CSE a bit to now make use of the proper reaching definitions (as a side note, it looks like some things can be cleaned up now that we have this).