Assertion failed 'lclNode->GetSsaNum() == SsaConfig::FIRST_SSA_NUM' during 'VN based copy prop'

[jakobbotsch]

Description

The following program hits an assert on x64 Linux/Windows.

Reproduction Steps

// Generated by Fuzzlyn v1.5 on 2022-03-30 14:07:21
// Run on X64 Linux
// Seed: 12709134569258617074
// Reduced from 365.3 KiB to 0.5 KiB in 00:04:43
// Hits JIT assert in Release:
// Assertion failed 'lclNode->GetSsaNum() == SsaConfig::FIRST_SSA_NUM' in 'Program:M66(S2):S0' during 'VN based copy prop' (IL size 18; hash 0x9c4ee8df; FullOpts)
// 
//     File: /__w/1/s/src/coreclr/jit/copyprop.cpp Line: 308
// 
public struct S0
{
    public byte F0;
}

public struct S2
{
    public S0 F0;
}

public class Program
{
    public static void Main()
    {
        var vr5 = new S2();
        M66(vr5);
    }

    public static S0 M66(S2 arg0)
    {
        short vr13 = default(short);
        var vr3 = (sbyte)(18446744073709551615UL * (ulong)vr13);
        sbyte vr14 = vr3;
        short vr15 = default(short);
        var vr0 = vr15;
        return arg0.F0;
    }
}

Expected behavior

No assert hit.

Actual behavior

Assert hit.

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

cc @dotnet/jit-contrib @SingleAccretion

[ghost]

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

Issue Details

---

Description

The following program hits an assert on x64 Linux.

Reproduction Steps

// Generated by Fuzzlyn v1.5 on 2022-03-30 14:07:21
// Run on X64 Linux
// Seed: 12709134569258617074
// Reduced from 365.3 KiB to 0.5 KiB in 00:04:43
// Hits JIT assert in Release:
// Assertion failed 'lclNode->GetSsaNum() == SsaConfig::FIRST_SSA_NUM' in 'Program:M66(S2):S0' during 'VN based copy prop' (IL size 18; hash 0x9c4ee8df; FullOpts)
// 
//     File: /__w/1/s/src/coreclr/jit/copyprop.cpp Line: 308
// 
public struct S0
{
    public byte F0;
}

public struct S2
{
    public S0 F0;
}

public class Program
{
    public static void Main()
    {
        var vr5 = new S2();
        M66(vr5);
    }

    public static S0 M66(S2 arg0)
    {
        short vr13 = default(short);
        var vr3 = (sbyte)(18446744073709551615UL * (ulong)vr13);
        sbyte vr14 = vr3;
        short vr15 = default(short);
        var vr0 = vr15;
        return arg0.F0;
    }
}

Expected behavior

No assert hit.

Actual behavior

Assert hit.

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

cc @dotnet/jit-contrib @SingleAccretion

Author:	jakobbotsch
Assignees:	-
Labels:	area-CodeGen-coreclr, untriaged
Milestone:	-

[SingleAccretion]

Will take a look.

[jakobbotsch]

This one might be related or a different issue entirely:

// Generated by Fuzzlyn v1.5 on 2022-03-30 14:37:05
// Run on X64 Windows
// Seed: 7764842575525975758
// Reduced from 228.5 KiB to 0.5 KiB in 00:02:55
// Hits JIT assert in Release:
// Assertion failed 'ssaNum != SsaConfig::RESERVED_SSA_NUM' in 'Program:M92(S2):S0' during 'VN based copy prop' (IL size 33; hash 0x52a4cf14; FullOpts)
// 
//     File: D:\a\_work\1\s\src\coreclr\jit\compiler.h Line: 356
// 
public struct S0
{
    public bool F0;
}

public struct S2
{
    public S0 F0;
}

public class Program
{
    public static IRuntime s_rt;
    public static void Main()
    {
        var vr1 = new S2();
        M92(vr1);
    }

    public static S0 M92(S2 arg0)
    {
        s_rt.WriteLine(arg0.F0.F0);
        return arg0.F0;
    }
}

public interface IRuntime
{
    void WriteLine<T>(T value);
}

public class Runtime : IRuntime
{
    public void WriteLine<T>(T value) => System.Console.WriteLine(value);
}

[SingleAccretion]

This is a regression caused by #66251.

In the baseline, we manage to produce a TYP_STRUCT LCL_FLD node:

fgMorphTree BB01, STMT00001 (after)
               [000013] ----G+------              *  RETURN    struct
               [000010] -----+------              \--*  LCL_FLD   struct V00 arg0         [+0]
                                                  \--*    ubyte  V00.F0 (offs=0x00) -> V03 tmp1         

After #66251, we no longer do, and so fail to mark the local as DNER (forcing dependent promotion). This is a very unsatisfying issue where there is an implicit contract between local address visitor and morph, the latter must recognize all patterns that the former does, for all TYP_STRUCT values, and mark all non-convertible uses of non-address-exposed promoted locals with DNER.

The proper fix is to support TYP_STRUCT.

The immediate fix is to recognize this in post-order morph and force dependent promotion.