Assertion failed '!foundDiff' during 'Linear scan register alloc'

[jakobbotsch]

// Generated by Fuzzlyn v1.5 on 2022-05-22 15:46:22
// Run on X64 Windows
// Seed: 6568846458402286114
// Reduced from 194.5 KiB to 0.5 KiB in 00:02:48
// Hits JIT assert in Release:
// Assertion failed '!foundDiff' in 'Program:M27(int,System.UInt64[][])' during 'Linear scan register alloc' (IL size 35; hash 0xf8af49d2; FullOpts)
// 
//     File: D:\a\_work\1\s\src\coreclr\jit\lsra.cpp Line: 2264
// 
public class Program
{
    public static ulong[] s_14;
    public static uint s_34;
    public static void Main()
    {
        var vr2 = new ulong[][]{new ulong[]{0}};
        M27(s_34, vr2);
    }

    public static void M27(uint arg4, ulong[][] arg5)
    {
        arg5[0][0] = arg5[0][0];
        for (int var7 = 0; var7 < 1; var7++)
        {
            return;
        }

        try
        {
            s_14 = arg5[0];
        }
        finally
        {
            arg4 = arg4;
        }
    }
}

Introduced by c190f6b, cc @kunalspathak

[ghost]

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

Issue Details

---

// Generated by Fuzzlyn v1.5 on 2022-05-22 15:46:22
// Run on X64 Windows
// Seed: 6568846458402286114
// Reduced from 194.5 KiB to 0.5 KiB in 00:02:48
// Hits JIT assert in Release:
// Assertion failed '!foundDiff' in 'Program:M27(int,System.UInt64[][])' during 'Linear scan register alloc' (IL size 35; hash 0xf8af49d2; FullOpts)
// 
//     File: D:\a\_work\1\s\src\coreclr\jit\lsra.cpp Line: 2264
// 
public class Program
{
    public static ulong[] s_14;
    public static uint s_34;
    public static void Main()
    {
        var vr2 = new ulong[][]{new ulong[]{0}};
        M27(s_34, vr2);
    }

    public static void M27(uint arg4, ulong[][] arg5)
    {
        arg5[0][0] = arg5[0][0];
        for (int var7 = 0; var7 < 1; var7++)
        {
            return;
        }

        try
        {
            s_14 = arg5[0];
        }
        finally
        {
            arg4 = arg4;
        }
    }
}

Introduced by c190f6b, cc @kunalspathak

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

[jakobbotsch]

Also the following:

// Generated by Fuzzlyn v1.5 on 2022-05-22 17:02:08
// Run on X64 Windows
// Seed: 16100522673054002921
// Reduced from 69.8 KiB to 0.8 KiB in 00:01:02
// Hits JIT assert in Release:
// Assertion failed 'cookie != nullptr' in 'Program:M47():bool' during 'Emit GC+EH tables' (IL size 66; hash 0x6cdf4e90; FullOpts)
// 
//     File: D:\a\_work\1\s\src\coreclr\jit\jiteh.cpp Line: 1086
// 
public class Program
{
    public static bool[][, ] s_2;
    public static short[, ][] s_8;
    public static bool[] s_10;
    public static ushort[][] s_29;
    public static void Main()
    {
        bool vr1 = M47();
    }

    public static bool M47()
    {
        bool var0 = default(bool);
        try
        {
            if (var0)
            {
                try
                {
                    if (s_10[0])
                    {
                        return s_2[0][0, 0];
                    }
                }
                finally
                {
                    s_8[0, 0][0] = 0;
                }
            }
        }
        finally
        {
            s_29 = s_29;
        }

        return true;
    }
}

[jakobbotsch]

We are hitting the cookie != nullptr variant in PGO tests as well:
https://dev.azure.com/dnceng/public/_build/results?buildId=1783685&view=ms.vss-test-web.build-test-results-tab&runId=47776050&resultId=196643&paneView=dotnet-dnceng.dnceng-anon-build-release-tasks.helix-anon-test-information-tab

[kunalspathak]

!foundDiff

This one is happening because we detect certain block is dead and remove the code inside it but we sometimes might decide to not delete the block. In those cases, we need to still make sure that we update liveness of variables. In #69421, I was only updating the liveness if we deleted the actual blocks.

cookie != nullptr

This one is interesting. We have chain of try-finally that looks like this. During dead block elimination, we eliminate BB08 and BB09. However, we fail to detect that BB11 could be eliminated as well because the only block that reaches BB11 is BB09. Going forward, we add labels to genMarkLabelsForCodegen and since no block is jumping to BB11 , we do not add label to it, do not generate a dedicated IG for it and hence do not have bbEmitCookie.

BB08 [0016]  1  1    BB04                  1       [???..???)-> BB15 (callf ) T1                  i internal LIR 
BB09 [0017]  1  1    BB15                  1       [???..???)-> BB11 (ALWAYS) T1      }           i internal LIR KEEP 
BB10 [0021]  2       BB02,BB07             1       [033..03E)-> BB14 (always)                     keep i LIR cfb cfe 
BB11 [0018]  1       BB09                  1       [???..???)-> BB17 (callf )                     i internal LIR 
BB12 [0019]  1       BB17                  1       [???..???)-> BB13 (ALWAYS)                     i internal LIR KEEP