Assertion failed 'unreached' in 'MyClass:Foo(System.Numerics.Vector`1[Single]):this' during 'Do value numbering' (IL size 9)

[kunalspathak]

Gets the assertion failure on windows/x64 when doing superpmi collection of System.Dynamic.Runtime.Tests.dll.

Repro steps:

python src\coreclr\scripts\superpmi.py collect --pmi -assemblies System.Dynamic.Runtime.Tests.dll

[kunalspathak]

@dotnet/jit-contrib , @briansull

[SingleAccretion]

Reproduction:

[MethodImpl(MethodImplOptions.NoInlining)]
private static void Problem()
{
    VectorDefault(new Vector<float>());
}

[MethodImpl(MethodImplOptions.NoInlining)]
static void VectorDefault<T>(T d)
{
    d = default(T);
}

Taking a closer look...

[SingleAccretion]

The issue is here:

runtime/src/coreclr/jit/valuenum.cpp

Lines 7483 to 7495 in 2aba0c5

	// Is the type being stored different from the type computed by the rhs?
	if ((rhs->TypeGet() != lhs->TypeGet()) && (lhs->OperGet() != GT_BLK))
	{
	// This means that there is an implicit cast on the rhs value
	//
	// We will add a cast function to reflect the possible narrowing of the rhs value
	//
	var_types castToType = lhs->TypeGet();
	var_types castFromType = rhs->TypeGet();
	bool isUnsigned = varTypeIsUnsigned(castFromType);
	rhsVNPair = vnStore->VNPairForCast(rhsVNPair, castToType, castFromType, isUnsigned);
	}

The relevant statement:

N004 (  9,  7) [000003] IA--G-------              *  ASG       simd16 (init)
N002 (  7,  5) [000005] *---G--N----              +--*  OBJ       simd16<System.Numerics.Vector`1[Single]>
N001 (  1,  1) [000000] -------N----              |  \--*  LCL_VAR   byref  V00 arg0         u:1 (last use)
N003 (  1,  1) [000002] ------------              \--*  CNS_INT   int    0

So, we have OBJ on the lhs, and CNS_INT on the rhs, and VNPairForCast is not equipped to handle that. The actual assert fires when we try to fold the cast from zero int to simd16.

As I am not an expert in this area, deferring the judgement on the proper fix to people who are.

[AndyAyersMS]

This is a common IR idiom for zero-initialization of a struct (one might prefer to see a struct (or simd)-typed zero, but we use an int).

Suspect you should you skip trees where OperIsInitBlkOp is true, and let code below handle it.

[SingleAccretion]

That sounds reasonable. Looks like the code in that branch was never prepared to handle GT_OBJs:

runtime/src/coreclr/jit/valuenum.cpp

Line 7682 in 2aba0c5

noway_assert(!"GT_OBJ can not be LHS when (tree->TypeGet() != TYP_STRUCT)!");

@AndyAyersMS I will see what I can do here, and hopefully learn something along the way, so I suppose you can assign me to this one.

[AndyAyersMS]

Do we know why we just started seeing this, or was it just always there and the SPMI run was the first time we noticed?

[kunalspathak]

Do we know why we just started seeing this, or was it just always there and the SPMI run was the first time we noticed?

Probably. We never ran SPMI on libraries tests. I noticed this while working on that pipeline. I am talking to @BruceForstall on how to surface these failures.

[SingleAccretion]

Probably

Agreed.

[briansull]

Triage Area: ValueNumbering

[JulieLeeMSFT]

Added @jakobbotsch

[jakobbotsch]

Looks like @echesakovMSFT ended up fixing the original repro with #53116, gonna see if I can find a different repro before I close this.

[jakobbotsch]

I haven't managed to find one, it looks like all places where we have a struct assignment on the left we call gtSetObjGcInfo which will change it to GT_BLK (for SIMD types).