Assertion failed 'interval->isSpilled' during 'LSRA allocate'

[jakobbotsch]

Description

The following program hits a JIT assert on arm32 when optimizing.

Reproduction Steps

// Generated by Fuzzlyn v1.5 on 2022-03-13 15:19:20
// Run on Arm Linux
// Seed: 13161118502102171269
// Reduced from 313.8 KiB to 1.2 KiB in 00:16:29
// Hits JIT assert in Release:
// Assertion failed 'interval->isSpilled' in 'Program:M52(C0)' during 'LSRA allocate' (IL size 103; hash 0xb4fc4553; FullOpts)
// 
//     File: /__w/1/s/src/coreclr/jit/lsra.cpp Line: 5924
// 
public interface I0
{
}

public interface I1
{
}

public class C0 : I0, I1
{
    public sbyte F0;
    public bool F1;
    public uint F2;
    public ushort F5;
    public C0(sbyte f0, bool f1, uint f2, ushort f5)
    {
        F0 = f0;
        F1 = f1;
        F2 = f2;
        F5 = f5;
    }
}

public class Program
{
    public static I1[][] s_18;
    public static ushort[][] s_43;
    public static I1 s_64;
    public static I0 s_88;
    public static void Main()
    {
        var vr6 = new C0(0, false, 0, 0);
        M52(vr6);
    }

    public static void M52(C0 argThis)
    {
        I1 vr9 = s_18[0][0];
        if (argThis.F1)
        {
            return;
        }

        if (argThis.F1)
        {
            try
            {
                s_43 = new ushort[][]{new ushort[]{0}};
            }
            finally
            {
                for (int var8 = 0; var8 < 2; var8++)
                {
                    s_64 = argThis;
                }

                C0 vr10 = new C0(0, true, 0, 0);
                s_88 = new C0(-1, true, 0, 0);
            }

            I1 vr12 = s_18[0][0];
        }
    }
}

Expected behavior

No assert hit.

Actual behavior

Assert hit.

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

No response

category:correctness
theme:register-allocator

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 a JIT assert on arm32 when optimizing.

Reproduction Steps

// Generated by Fuzzlyn v1.5 on 2022-03-13 15:19:20
// Run on Arm Linux
// Seed: 13161118502102171269
// Reduced from 313.8 KiB to 1.2 KiB in 00:16:29
// Hits JIT assert in Release:
// Assertion failed 'interval->isSpilled' in 'Program:M52(C0)' during 'LSRA allocate' (IL size 103; hash 0xb4fc4553; FullOpts)
// 
//     File: /__w/1/s/src/coreclr/jit/lsra.cpp Line: 5924
// 
public interface I0
{
}

public interface I1
{
}

public class C0 : I0, I1
{
    public sbyte F0;
    public bool F1;
    public uint F2;
    public ushort F5;
    public C0(sbyte f0, bool f1, uint f2, ushort f5)
    {
        F0 = f0;
        F1 = f1;
        F2 = f2;
        F5 = f5;
    }
}

public class Program
{
    public static I1[][] s_18;
    public static ushort[][] s_43;
    public static I1 s_64;
    public static I0 s_88;
    public static void Main()
    {
        var vr6 = new C0(0, false, 0, 0);
        M52(vr6);
    }

    public static void M52(C0 argThis)
    {
        I1 vr9 = s_18[0][0];
        if (argThis.F1)
        {
            return;
        }

        if (argThis.F1)
        {
            try
            {
                s_43 = new ushort[][]{new ushort[]{0}};
            }
            finally
            {
                for (int var8 = 0; var8 < 2; var8++)
                {
                    s_64 = argThis;
                }

                C0 vr10 = new C0(0, true, 0, 0);
                s_88 = new C0(-1, true, 0, 0);
            }

            I1 vr12 = s_18[0][0];
        }
    }
}

Expected behavior

No assert hit.

Actual behavior

Assert hit.

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

No response

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

[kunalspathak]

I spent some time investigating this and seems there are multiple issues out here. I am not sure if they are related though.

Problem# 1:

If we see the repro, all the code in M52 is dead because argThis.F1 == false. But ignoring that, lets take a look at the loop:

for (int var8 = 0; var8 < 2; var8++)
{
    s_64 = argThis;
}

We start with something like this:

BB08 [0004]  2     0 BB04                  1       [031..035)-> BB10 ( cond )    H0 F finally {   keep i flet 
BB09 [0005]  2     0 BB08,BB09             8     0 [035..043)-> BB09 ( cond )    H0               i Loop bwd bwd-target 
BB10 [0007]  2     0 BB08,BB09             1       [043..05C)        (finret)    H0   }           i hascall newobj 

but then during assertion prop, we convert the loop to an infinite loop:

VN relop based constant assertion prop in BB09:
Assertion index=#09: [000048] != 0
N003 (  3,  4) [000048] -------------             *  CNS_INT   int    1
Propagating #01 #02 #03 #04 #05 #06 #07 #08 #09 #10 #11 #12 for BB09, stmt STMT00010, tree [000049], tree -> #09
Re-morphing this stmt:
STMT00010 ( 0x03F[E-] ... 0x041 )
N004 (  5,  6) [000049] -------------             *  JTRUE     void   $VN.Void
N003 (  3,  4) [000048] -------------             \--*  CNS_INT   int    1


removing useless STMT00010 ( 0x03F[E-] ... 0x041 )
N004 (  5,  6) [000049] -------------             *  JTRUE     void   $VN.Void
N003 (  3,  4) [000048] -------------             \--*  CNS_INT   int    1
 from BB09

Conditional folded at BB09
BB09 becomes a BBJ_ALWAYS to BB09
optAssertionPropMain removed tree:
N004 (  5,  6) [000049] -------------             *  JTRUE     void   $VN.Void
N003 (  3,  4) [000048] -------------             \--*  CNS_INT   int    1

which looks like this:

BB08 [0004]  2     0 BB04                  1       [031..035)                    H0 F finally {   keep i flet 
BB09 [0005]  2     0 BB08,BB09             8     0 [035..043)-> BB09 (always)    H0               i Loop bwd bwd-target 
BB10 [0007]  0     0                       1       [043..05C)        (finret)    H0   }           i hascall newobj 

This also happens on other architectures as seen below:

windows x64 assembly code

G_M39422_IG01:
       push     rbp
       push     rsi
       sub      rsp, 40
       lea      rbp, [rsp+30H]
       mov      qword ptr [rbp-10H], rsp
       mov      gword ptr [rbp+10H], rcx
                                                ;; bbWeight=0    PerfScore 0.00
G_M39422_IG02:
       mov      rcx, 0xD1FFAB1E
       mov      edx, 15
       call     CORINFO_HELP_GETSHARED_NONGCSTATIC_BASE
       mov      rcx, 0xD1FFAB1E
       mov      rcx, gword ptr [rcx]
       mov      edx, dword ptr [rcx+8]
       test     edx, edx
       je       SHORT G_M39422_IG08
       mov      rcx, gword ptr [rcx+16]
       cmp      dword ptr [rcx+8], 0
       jbe      SHORT G_M39422_IG08
       mov      rdx, gword ptr [rbp+10H]
       cmp      byte  ptr [rdx+15], 0
       je       SHORT G_M39422_IG06
                                                ;; bbWeight=1    PerfScore 18.00
G_M39422_IG03:
       add      rsp, 40
       pop      rsi
       pop      rbp
       ret
                                                ;; bbWeight=1    PerfScore 2.25
G_M39422_IG04:
       mov      rcx, 0xD1FFAB1E      ; System.UInt16[][]
       mov      edx, 1
       call     CORINFO_HELP_NEWARR_1_OBJ
       mov      rsi, rax
       mov      rcx, 0xD1FFAB1E      ; System.UInt16[]
       mov      edx, 1
       call     CORINFO_HELP_NEWARR_1_VC
       lea      rcx, bword ptr [rsi+16]
       mov      rdx, rax
       call     CORINFO_HELP_ASSIGN_REF
       mov      rcx, 0xD1FFAB1E
       mov      rdx, rsi
       call     CORINFO_HELP_CHECKED_ASSIGN_REF
       nop
                                                ;; bbWeight=1    PerfScore 6.75
G_M39422_IG05:
       mov      rcx, rsp
       call     G_M39422_IG09
                                                ;; bbWeight=1    PerfScore 1.25
G_M39422_IG06:
       nop
                                                ;; bbWeight=1    PerfScore 0.25
G_M39422_IG07:
       add      rsp, 40
       pop      rsi
       pop      rbp
       ret
                                                ;; bbWeight=1    PerfScore 2.25
G_M39422_IG08:
       call     CORINFO_HELP_RNGCHKFAIL
       int3
                                                ;; bbWeight=0    PerfScore 0.00
G_M39422_IG09:
       push     rbp
       push     rsi
       sub      rsp, 40
       mov      rbp, qword ptr [rcx+32]
       mov      qword ptr [rsp+20H], rbp
       lea      rbp, [rbp+30H]
                                                ;; bbWeight=1    PerfScore 5.75
G_M39422_IG10:
       xor      esi, esi
                                                ;; bbWeight=1    PerfScore 0.25
G_M39422_IG11:
       mov      rcx, 0xD1FFAB1E
       mov      rdx, gword ptr [rbp+10H]
       call     CORINFO_HELP_CHECKED_ASSIGN_REF
       inc      esi
       jmp      SHORT G_M39422_IG11

Problem# 2:

In LSRA, for V13 interval, we have 3 RefPositions. #7 and #105 are marked as lastUse.

Interval  8: (V13) ref RefPositions {#6@10 #7@13 #105@127} physReg:NA Preferences=[allInt] RelatedInterval <V08/L5>

For #7 allocation, we allocate "r4" , we mark it as inActive since it is marked as lastUse. We return "r4" to the free registers pool.
For #8 (since it is a related interval to V13), we assign it "r4" again, however we don't spill the interval because the register "r4" was picked up from free registers. Also, during unassignPhysReg, we don't set V13 interval as spilled because we would only do it had V13 was active as seen:

runtime/src/coreclr/jit/lsra.cpp

Line 3545 in 82239a2

bool spill = assignedInterval->isActive && nextRefPosition != nullptr;

I tried to loosen the condition by following but it adds lot of regression due to the fact that we would always spill at the def for "single-def" intervals.

    bool spill = false;
    if (nextRefPosition != nullptr)
    {
        // Spilling is needed only if there is any refPosition after this.

        if (assignedInterval->isActive)
        {
            // Since the currently assigned interval is active, it should be spilled.
            spill = true;
        }
        else if ((spillRefPosition->lastUse) && !RefTypeIsDef(nextRefPosition->refType))
        {
            // Alternatively, if current refPosition is marked as "lastUse" and the next one
            // is not a def, we should still spill this interval.
            spill = true;
        }
    }

During allocating for #105, we again pick "r4".

-----------------------------------+----+----+----+----+----+----+
Loc RP#  Name Type  Action    Reg  |r0  |r1  |r2  |r3  |r4  |r5  |
-----------------------------------+----+----+----+----+----+----+
                                   |V0 a|    |    |    |    |    |
  0.#0   V0   Parm   COVRS(A) r1   |    |V0 a|    |    |    |    |
  9.#5   I11  Use *  Keep     r4   |    |V0 a|    |    |I11a|    |
 10.#6   V13  Def    COVRS(A) r4   |    |V0 a|    |    |V13a|    |
 13.#7   V13  Use *  Keep     r4   |    |V0 a|    |    |V13i|    |
 14.#8   V8   Def    COVRS(A) r4   |    |V0 a|    |    |V8 a|    |
...
...
121.#104 BB6  PredBB0              |    |    |    |    |    |    |
127.#105 V13  Use *  ReLod    NA   |    |    |    |    |    |    |
                     THISA(A) r4   |    |    |    |    |V13a|    |
128.#106 V10  Def    ORDER(A) r1   |    |V10a|    |    |    |    |

During resolve phase, we realize that #105 was a reload and expect to see that the interval V13 was supposed to have been spilled but it was not. This is a very basic use case which should have worked and not sure what changed recently that broke (to my knowledge, nothing changed in LSRA).

I verified and the issue doesn't exist in .NET 6 and mainly because we don't CSE the V13 . Below is the code in .NET 6. Here we don't even see the infinite loop that we are seeing now. So, most likely they are related and with aggressive CSEing, it is exposing some of the LSRA problems.

Edit: I was looking at incomplete code. The arm code in .NET 6 also generates infinite loop but don't hit the assert. It is because it has zeroref cse0. I have updated the code below.

.NET 6 arm code

; Assembly listing for method Program2:M52(C0)
; Emitting BLENDED_CODE for generic ARM CPU - Unix
; optimized code
; r11 based frame
; fully interruptible
; No PGO data
; 0 inlinees with PGO data; 4 single block inlinees; 0 inlinees without PGO data
; invoked as altjit
; Final local variable assignments
;
;  V00 arg0         [V00,T01] (  4, 11   )     ref  ->  [sp+04H]   class-hnd EH-live single-def
;  V01 loc0         [V01,T00] (  3, 17   )     int  ->   r2
;# V02 OutArgs      [V02    ] (  1,  1   )  lclBlk ( 0) [sp+00H]   "OutgoingArgSpace"
;  V03 tmp1         [V03,T02] (  3,  6   )     ref  ->   r4         class-hnd exact single-def "dup spill"
;* V04 tmp2         [V04    ] (  0,  0   )     ref  ->  zero-ref    class-hnd exact single-def "NewObj constructor temp"
;* V05 tmp3         [V05    ] (  0,  0   )     ref  ->  zero-ref    class-hnd exact single-def "NewObj constructor temp"
;  V06 tmp4         [V06,T04] (  2,  4   )     ref  ->   r0         single-def "arr expr"
;  V07 tmp5         [V07,T03] (  3,  6   )     ref  ->   r0         single-def "arr expr"
;  V08 tmp6         [V08,T05] (  2,  4   )     ref  ->   r2         single-def "argument with side effect"
;  V09 tmp7         [V09,T06] (  2,  4   )     ref  ->   r1         single-def "arr expr"
;  V10 tmp8         [V10,T07] (  2,  4   )     ref  ->   r1         single-def "arr expr"
;  V11 PSPSym       [V11    ] (  1,  1   )     int  ->  [sp+08H]   do-not-enreg[X] addr-exposed "PSPSym"
;* V12 tmp10        [V12    ] (  0,  0   )     ref  ->  zero-ref    "optAddCopies"
;* V13 cse0         [V13,T08] (  0,  0   )     int  ->  zero-ref    "CSE - aggressive"
;
; Lcl frame size = 12

G_M39422_IG01:
            push    {r4,r11,lr}
            sub     sp, 12
            add     r11, sp, 16
            add     r1, sp, 24
            str     r1, [sp+0x08]       // [V11 PSPSym]
            str     r0, [sp+0x04]       // [V00 arg0]
                                                ;; bbWeight=1    PerfScore 6.00
G_M39422_IG02:
            movw    r0, 0xd1ff
            movt    r0, 0xd1ff
            movs    r1, 15
            movw    r3, 0xd1ff
            movt    r3, 0xd1ff
            blx     r3          // CORINFO_HELP_GETSHARED_NONGCSTATIC_BASE
            movw    r0, 0xd1ff
            movt    r0, 0xd1ff
            ldr     r0, [r0]
            movs    r1, 0
            ldr     r3, [r0+4]
            cmp     r1, r3
            bhs     SHORT G_M39422_IG08
            ldr     r0, [r0+8]
            ldr     r0, [r0+4]
            cmp     r1, r0
            bhs     SHORT G_M39422_IG08
            ldr     r1, [sp+0x04]       // [V00 arg0]
            ldrb    r0, [r1+11]
            cmp     r0, 0
            beq     SHORT G_M39422_IG07
                                                ;; bbWeight=1    PerfScore 21.00
G_M39422_IG03:
            add     sp, 12
            pop     {r4,r11,pc}
                                                ;; bbWeight=1    PerfScore 2.00
G_M39422_IG04:
            movw    r0, 0xd1ff
            movt    r0, 0xd1ff
            movs    r1, 1
            movw    r3, 0xd1ff
            movt    r3, 0xd1ff
            blx     r3          // CORINFO_HELP_NEWARR_1_OBJ
            mov     r4, r0
            movw    r0, 0xd1ff
            movt    r0, 0xd1ff
            movs    r1, 1
            movw    r3, 0xd1ff
            movt    r3, 0xd1ff
            blx     r3          // CORINFO_HELP_NEWARR_1_VC
            mov     r2, r0
            mov     r0, r4
            movs    r1, 0
            movw    r3, 0xd1ff
            movt    r3, 0xd1ff
            blx     r3          // CORINFO_HELP_ARRADDR_ST
            movw    r0, 0xd1ff
            movt    r0, 0xd1ff
            mov     r1, r4
            movw    r12, 0xd1ff
            movt    r12, 0xd1ff
            blx     r12         // CORINFO_HELP_ASSIGN_REF
            movw    lr, LOW ADDRESS G_M39422_IG06
            movt    lr, HIGH ADDRESS G_M39422_IG06
            b       SHORT G_M39422_IG09
                                                ;; bbWeight=1    PerfScore 28.00
G_M39422_IG05:
            nop
                                                ;; bbWeight=1    PerfScore 1.00
G_M39422_IG06:
            movw    r1, 0xd1ff
            movt    r1, 0xd1ff
            ldr     r1, [r1]
            ldr     r1, [r1+8]
            movs    r0, 0
            ldr     r1, [r1+4]
            cmp     r0, r1
            bhs     SHORT G_M39422_IG08
                                                ;; bbWeight=1    PerfScore 8.00
G_M39422_IG07:
            add     sp, 12
            pop     {r4,r11,pc}
                                                ;; bbWeight=1    PerfScore 2.00
G_M39422_IG08:
            movw    r3, 0xd1ff
            movt    r3, 0xd1ff
            blx     r3          // CORINFO_HELP_RNGCHKFAIL
            bkpt
                                                ;; bbWeight=0    PerfScore 0.00
G_M39422_IG09:
            push    {r3,r4,r11,lr}
            add     r3, r11, 8
            str     r3, [sp]
                                                ;; bbWeight=1    PerfScore 3.00
G_M39422_IG10:
            movs    r2, 0
                                                ;; bbWeight=1    PerfScore 1.00
G_M39422_IG11:
            movw    r0, 0xd1ff
            movt    r0, 0xd1ff
            ldr     r1, [r11-0x0c]      // [V00 arg0]
            movw    r12, 0xd1ff
            movt    r12, 0xd1ff
            blx     r12         // CORINFO_HELP_ASSIGN_REF
            adds    r2, r2, 1
            b       SHORT G_M39422_IG11
                                                ;; bbWeight=8    PerfScore 64.00

; Total bytes of code 242, prolog size 16, PerfScore 160.20, instruction count 84, allocated bytes for code 242 (MethodHash=ca396601) for method Program2:M52(C0

One thing to note though is the assert doesn't fire on any other platforms because we get rid of the block containing #105 , but it is not done in arm because it is part of callfinally pair.

I will continue to investigate both these problems.

[kunalspathak]

While working on this issue, I realized that since lvSingleDefRegCandidate is set during lvaMarkLclRefs (which is very earlier phase), lot of single defs which are produced in CSE are missed out and we do not enregister them in EHWrite thru (single-def) scenarios. I will look into it in a separate PR.

[kunalspathak]

Not sure if my observation is correct, but here is BB flow graph we have:

-----------------------------------------------------------------------------------------------------------------------------------------
BBnum BBid ref try hnd preds           weight    lp [IL range]     [jump]      [EH region]         [flags]
-----------------------------------------------------------------------------------------------------------------------------------------
BB01 [0000]  1                             1       [000..012)-> BB07 ( cond )                     i idxlen LIR 
BB02 [0001]  1       BB01                  1       [012..013)        (return)                     i LIR 
BB04 [0003]  0  0                          1       [01B..031)-> BB08 (callf ) T0      try {       keep i try hascall idxlen new[] LIR 
BB05 [0010]  0  0                          1       [???..???)-> BB06 (ALWAYS) T0      }           i internal LIR KEEP 
BB06 [0008]  1       BB05                  1       [05C..066)                                     i idxlen ftarget LIR 
BB07 [0009]  2       BB01,BB06             1       [066..067)        (return)                     i LIR 
BB11 [0016]  0                             0       [???..???)        (throw )                     keep i internal rare LIR 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ funclets follow
BB08 [0004]  2     0 BB04                  1       [031..035)                    H0 F finally {   keep i flet LIR 
BB09 [0005]  2     0 BB08,BB09             8     0 [035..043)-> BB09 (always)    H0   }           i Loop bwd bwd-target LIR 
-----------------------------------------------------------------------------------------------------------------------------------------

During liveness, we have following def/use:

BB01 USE(1)={V00                } + ByrefExposed + GcHeap
     DEF(4)={    V08 V07 V13 V14}

BB02 USE(0)={}
     DEF(0)={}

BB04 USE(0)={       }
     DEF(2)={V03 V04}

BB05 USE(0)={}
     DEF(0)={}

BB06 USE(1)={        V13} + ByrefExposed + GcHeap
     DEF(2)={V09 V10    }

BB07 USE(0)={}
     DEF(0)={}

BB11 USE(0)={}
     DEF(0)={}

BB08 USE(0)={   }
     DEF(1)={V01}

BB09 USE(2)={V01 V00}
     DEF(1)={V01    }

As seen, there is a definition of V13 in BB01 and a use in BB06. There is also a use of V13 in BB01, but I assume we don't show that in the above dump and is implicit:

               [000255] ----G--------      t255 = *  IND       ref   
                                                   /--*  t255   ref    
N003 (  6, 10) [000243] DA--G--------             *  STORE_LCL_VAR ref    V13 cse0         d:1
N004 (  1,  1) [000244] -------------      t244 =    LCL_VAR   ref    V13 cse0         u:1 <l:$140, c:$81>
                                                   /--*  t244   ref    

Now, when we do inter-block analysis, I was hoping to see the liveness of V13 propagates from BB06 and through the FINALLY block BB05 up to BB4 and eventually to BB01. However, this is what I see after fgInterBlockLocalVarLiveness():

BB01 IN (1)={V00} + ByrefExposed + GcHeap
     OUT(0)={   }

BB02 IN (0)={}
     OUT(0)={}

BB04 IN (1)={V00}
     OUT(1)={V00}

BB05 IN (2)={V00 V13} + ByrefExposed + GcHeap
     OUT(2)={V00 V13} + ByrefExposed + GcHeap

BB06 IN (1)={V13} + ByrefExposed + GcHeap
     OUT(0)={   }

BB07 IN (0)={}
     OUT(0)={}

BB11 IN (0)={}
     OUT(0)={}

BB08 IN (1)={    V00}
     OUT(2)={V01 V00}

BB09 IN (2)={V01 V00}
     OUT(2)={V01 V00}

Here, since V13 is used in BB06, it is in bbLiveIn of BB06 and then to in/out of BB05. But when we iterate the successors of BB04, we never get BB05 (because it is tail of CALLF/ALWAYS pair) and we never propagate the V13's liveness upwards.

@AndyAyersMS or @BruceForstall - Am I correct in my analysis so far?

Due to this, we wrongly mark the "use" of V13 in BB01 as "lastUse" which is wrong and just the "use" of V13 in BB06 should be lastUse. This wrongly makes LSRA mark the interval inactive in BB01 itself and we end up with the assert as explained in my previous comments.

[AndyAyersMS]

I think the liveness is supposed to propagate back up through the finally, but this is one of those odd cases where the finally never returns, so BB09 does not have BB05 as a successor.

Thus BB05/BB06 are actually unreachable. In fact, so is BB04 and hence BB08 and BB09.

It could be that RBO or similar has kicked in but for some reason we don't realize we can delete BB04/BB05/BB06/BB08/BB09 (or don't try to delete them) and the unreachable blocks cause trouble.

[kunalspathak]

where the finally never returns

Yes, that is wrong too which is "Problem# 1" I mentioned above. But regardless, if users write an infinite loop for some reason such that finally never returns, we need to handle it correctly.

[kunalspathak]

we don't realize we can delete BB04/BB05/BB06/BB08/BB09 (or don't try to delete them) and the unreachable blocks cause trouble.

This is on Arm and BB04/BB05 are callfinally/always pair which have stricter rules about removal. It never has BBF_RETLESS_CALL flag:

runtime/src/coreclr/jit/block.cpp

Lines 1561 to 1563 in 2306813

	// that case, the BBJ_CALLFINALLY flags has BBF_RETLESS_CALL set. Note that ARM never has
	// "retless" BBJ_CALLFINALLY blocks due to a requirement to use the BBJ_ALWAYS for
	// generating code.

and we never remove those blocks, even if they are not reachable. Not sure historically why we couldn't relax these rules a little bit.

runtime/src/coreclr/jit/fgopt.cpp

Lines 6105 to 6113 in 2306813

	// Don't remove the BBJ_ALWAYS block of a BBJ_CALLFINALLY/BBJ_ALWAYS pair.
	if (block->countOfInEdges() == 0 && bPrev->bbJumpKind == BBJ_CALLFINALLY)
	{
	assert(bPrev->isBBCallAlwaysPair());
	noway_assert(!(bPrev->bbFlags & BBF_RETLESS_CALL));
	noway_assert(block->bbJumpKind == BBJ_ALWAYS);
	bPrev = block;
	continue;
	}

[AndyAyersMS]

Right, that explains why this is an arm only issue. We probably are too conservative. I suspect we could allow removal in some cases.

We may need some combination of:

• upgrade our ability to remove dead code so downstream phases don't have to deal with it
• make downstream phases more tolerant of dead code