Assertion failed 'block->bbNatLoopNum == loopNum' during 'Optimize Valnum CSEs'

[jakobbotsch]

// Generated by Fuzzlyn v1.6 on 2022-08-28 15:37:22
// Run on Arm64 Linux
// Seed: 12944707798274443197
// Reduced from 38.4 KiB to 0.5 KiB in 00:01:30
// Hits JIT assert in Release:
// Assertion failed 'block->bbNatLoopNum == loopNum' in 'Program:Main(Fuzzlyn.ExecutionServer.IRuntime)' during 'Optimize Valnum CSEs' (IL size 58; hash 0xade6b36b; FullOpts)
// 
//     File: /__w/1/s/src/coreclr/jit/fgdiagnostic.cpp Line: 3935
// 
public class Program
{
    public static ushort[] s_4;
    public static short s_23;
    public static void Main()
    {
        try
        {
            for (int vr0 = 0; vr0 < 2; vr0++)
            {
                for (int vr1 = 0; vr1 < 1; vr1++)
                {
                    s_23 = (short)(s_4[0] % -3635746572523657308L);
                }
            }
        }
        finally
        {
            M19();
        }
    }

    public static bool M19()
    {
        return default(bool);
    }
}

Saw several of these on arm64 only.

cc @dotnet/jit-contrib

Build Information

Build: https://dev.azure.com/dnceng/9ee6d478-d288-47f7-aacc-f6e6d082ae6d/_build/results?buildId=1970696
Build error leg or test failing: Exploratory Linux arm64 checked coreclr JIT / Summarize (Linux arm64)
Pull request: #73233

Error Message

Fill the error message using known issues guidance.

{
  "ErrorMessage": "// Assertion failed 'block->bbNatLoopNum == loopNum' in 'Program:Main(Fuzzlyn.ExecutionServer.IRuntime)' during 'Optimize Valnum CSEs' (IL size 67; hash 0xade6b36b; FullOpts)",
  "BuildRetry": false
}

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

Issue Details

---

// Generated by Fuzzlyn v1.6 on 2022-08-28 15:37:22
// Run on Arm64 Linux
// Seed: 12944707798274443197
// Reduced from 38.4 KiB to 0.5 KiB in 00:01:30
// Hits JIT assert in Release:
// Assertion failed 'block->bbNatLoopNum == loopNum' in 'Program:Main(Fuzzlyn.ExecutionServer.IRuntime)' during 'Optimize Valnum CSEs' (IL size 58; hash 0xade6b36b; FullOpts)
// 
//     File: /__w/1/s/src/coreclr/jit/fgdiagnostic.cpp Line: 3935
// 
public class Program
{
    public static ushort[] s_4;
    public static short s_23;
    public static void Main()
    {
        try
        {
            for (int vr0 = 0; vr0 < 2; vr0++)
            {
                for (int vr1 = 0; vr1 < 1; vr1++)
                {
                    s_23 = (short)(s_4[0] % -3635746572523657308L);
                }
            }
        }
        finally
        {
            M19();
        }
    }

    public static bool M19()
    {
        return default(bool);
    }
}

Saw several of these on arm64 only.

cc @dotnet/jit-contrib

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

[jakobbotsch]

Exposed by checks added in #74308 maybe? cc @AndyAyersMS

[AndyAyersMS]

Yeah, likely so. The implication is that CSE is introducing or altering control flow, which is surprising.

[AndyAyersMS]

Probably not a 7.0 issue but will need to drill in to confirm.

[AndyAyersMS]

CSE invokes morph, and on ARM64 this can introduce references to throw blocks. These blocks may be placed within the span of an existing loop but not marked as loop blocks. Hence the assert.

Since these blocks contain only throw helper calls, the fact that they're not marked as loop blocks should not cause any actual problems.

Moving this out of 7.0.

[AndyAyersMS]

More specifically, we have a loop within a try where the try ends in a conditional branch:

-----------------------------------------------------------------------------------------------------------------------------------------
BBnum BBid ref try hnd preds           weight    lp [IL range]     [jump]      [EH region]         [flags]
-----------------------------------------------------------------------------------------------------------------------------------------
BB08 [0016]  1                             1       [???..???)                                     internal 
BB01 [0000]  1  0    BB08                  1       [000..004)                 T0      try {       keep i try 
BB09 [0017]  1  0    BB01                  1       [004..???)                 T0                  internal idxlen LoopPH 
BB02 [0001]  2  0    BB05,BB09             4     0 [004..008)                 T0                  i Loop bwd bwd-target 
BB03 [0002]  1  0    BB02                 16     0 [008..028)                 T0                  i idxlen bwd bwd-target 
BB04 [0015]  1  0    BB03                  2     0 [008..028)                 T0                  i Loop idxlen bwd bwd-target 
BB05 [0004]  1  0    BB04                  4     0 [028..030)-> BB02 ( cond ) T0      }           i bwd 
BB06 [0012]  1       BB05                  1       [032..03A)        (return)                     keep i cfb cfe 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ funclets follow
BB07 [0007]  1     0                       0       [032..039)        (finret)    H0 F fault { }   keep i rare flet 
-----------------------------------------------------------------------------------------------------------------------------------------

fgFindInsertPoint is given the try region with desired "after" of BB04 and ends up splicing the block right there. A second block also gets added. And the result is:

Trees after Optimize Valnum CSEs

-----------------------------------------------------------------------------------------------------------------------------------------
BBnum BBid ref try hnd preds           weight    lp [IL range]     [jump]      [EH region]         [flags]
-----------------------------------------------------------------------------------------------------------------------------------------
BB08 [0016]  1                             1       [???..???)                                     internal 
BB01 [0000]  1  0    BB08                  1       [000..004)                 T0      try {       keep i try 
BB09 [0017]  1  0    BB01                  1       [004..???)                 T0                  internal idxlen LoopPH 
BB02 [0001]  2  0    BB05,BB09             4     0 [004..008)                 T0                  i Loop bwd bwd-target 
BB03 [0002]  1  0    BB02                 16     0 [008..028)                 T0                  i idxlen bwd bwd-target 
BB04 [0015]  1  0    BB03                  2     0 [008..028)-> BB05 (always) T0                  i Loop idxlen bwd bwd-target 
BB11 [0019]  0  0                          0       [???..???)        (throw ) T0                  keep i internal rare 
BB10 [0018]  0  0                          0       [???..???)        (throw ) T0                  keep i internal rare 
BB05 [0004]  1  0    BB04                  4     0 [028..030)-> BB02 ( cond ) T0      }           i bwd 
BB06 [0012]  1       BB05                  1       [032..03A)        (return)                     keep i cfb cfe 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ funclets follow
BB07 [0007]  1     0                       0       [032..039)        (finret)    H0 F fault { }   keep i rare flet 
-----------------------------------------------------------------------------------------------------------------------------------------

where the new BB11 and BB10 are the troublemakers.