Closed
Description
// Generated by Fuzzlyn v2.9 on 2025-04-29 21:12:44
// Run on X64 Windows
// Seed: 1988339208440149902-vectort,vector128,vector256,x86aes,x86avx,x86avx2,x86avx512bw,x86avx512bwvl,x86avx512cd,x86avx512cdvl,x86avx512dq,x86avx512dqvl,x86avx512f,x86avx512fvl,x86avx512fx64,x86bmi1,x86bmi1x64,x86bmi2,x86bmi2x64,x86fma,x86lzcnt,x86lzcntx64,x86pclmulqdq,x86popcnt,x86popcntx64,x86sse,x86ssex64,x86sse2,x86sse2x64,x86sse3,x86sse41,x86sse41x64,x86sse42,x86sse42x64,x86ssse3,x86x86base
// Reduced from 63.5 KiB to 1.0 KiB in 00:01:26
// Hits JIT assert in Release:
// Assertion failed 'm_dfsTree != nullptr' in 'Program:M1(C0)' during 'Do value numbering' (IL size 72; hash 0xc7c374c5; FullOpts)
//
// File: D:\a\_work\1\s\src\coreclr\jit\valuenum.cpp Line: 10867
//
using System;
using System.Numerics;
using System.Runtime.Intrinsics;
using System.Runtime.Intrinsics.X86;
public class C0
{
public byte F0;
public ushort F4;
}
public class Program
{
public static void Main()
{
var vr1 = new C0();
M1(vr1);
}
public static void M1(C0 argThis)
{
switch ((Bmi1.AndNot(4294967295U, argThis.F4) & argThis.F0))
{
case 0:
{
Vector<long> var0 = Vector.Create<long>(0);
System.Console.WriteLine(var0);
}
break;
case 1:
{
}
break;
case 2:
{
}
break;
case 3:
{
}
break;
case 4:
{
}
break;
default:
{
}
break;
}
}
}
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Participants
Activity
dotnet-policy-service commentedon Apr 29, 2025
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.
[-]JIT:[/-][+]JIT: Assertion failed 'm_dfsTree != nullptr'[/+]BruceForstall commentedon Apr 29, 2025
@dotnet/jit-contrib
amanasifkhalid commentedon Apr 30, 2025
If early value propagation decides to fold a null check away, any existing flowgraph annotations need to be invalidated due to the change in flowgraph shape. Value numbering tolerates the loop data structures being null, but oddly expects the DFS tree to always be available -- I'm guessing this assert has been overzealous for a long time, and the null check fold in early prop just doesn't kick in often.
amanasifkhalid commentedon Apr 30, 2025
With the assert replaced with a DFS tree re-computation, I'm now hitting an assert in the VM:
I'm guessing there's something illegal about this transformation.
amanasifkhalid commentedon Apr 30, 2025
Turns out this assert was obscuring an AV in the JIT from the dominance tree being null in a later phase. Not sure if it's interesting, but here's the transformation we're doing:
The AndNot call is folded away because
~4294967295(or~0xFFFFFFFF) is 0, so all the Ands will reduce to 0 regardless ofargThis's values, but we keep the null check around in aGT_COMMAnode. So before early prop, we have this tree:Null check folding finds the
GT_INDnode below theGT_COMMA, and gets rid of the null check and folds theGT_ANDaway, so we end up with the following:This looks valid to me; the second read to
argThisis preserved so we can throw a NRE if needed. Now that we've folded the switch expression into a constant, we can fold it into aBBJ_ALWAYS, hence the flowgraph change.JIT: Disallow flowgraph modifications during VN opts (dotnet#115197)