JIT: Allow early prop to reorder null checks

[jakobbotsch]

We currently do not allow two null checks on separate values to be
reordered with one another. This should be fine to do as the exceptions
thrown are indistinguishable from one another up to debug information,
which we do not make guarantees about in optimized builds.
We can use the machinery added in #70893 to easily do this.

The net effect of this change is that we then allow removing a null
check if there is a later equivalent null check, even if it comes after
another unrelated null check.

[ghost]

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

Issue Details

---

We currently do not allow two null checks on separate values to be
reordered with one another. This should be fine to do as the exceptions
thrown are indistinguishable from one another up to debug information,
which we do not make guarantees about in optimized builds.

The net effect of this change is that we then allow removing a null
check if there is a later equivalent null check, even if it comes after
another unrelated null check.

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

[jakobbotsch]

A few example diffs:

        ; gcrRegs -[rax]
        ; byrRegs +[rax]
        mov      rdi, gword ptr [rax]
        ; gcrRegs +[rdi]
-       cmp      byte  ptr [rdi], dil
        add      rdi, 0x800
        ; gcrRegs -[rdi]
        ; byrRegs +[rdi]
        mov      ebp, dword ptr [rax+8]
        dec      ebp
        imul     ebp, dword ptr [rdi+20]
        lea      r15, bword ptr [rdi+24]

        mov      rax, r14
        ; gcrRegs -[rax]
        ; byrRegs +[rax]
        mov      rdi, gword ptr [rax]
        ; gcrRegs +[rdi]
-       cmp      byte  ptr [rdi], dil
        lea      rdx, bword ptr [rdi+0800H]
        ; byrRegs +[rdx]
        mov      edi, dword ptr [rax+8]
        ; gcrRegs -[rdi]
        dec      edi
        imul     edi, dword ptr [rdx+20]

G_M1099_IG01:        ; gcrefRegs=00000000 {}, byrefRegs=00000000 {}, byref, nogc <-- Prolog IG
        push     rdi
        push     rsi
        push     rbx
        sub      rsp, 32
        vzeroupper
                                                ;; size=10 bbWeight=1    PerfScore 4.25
 G_M1099_IG02:        ; gcrefRegs=00000000 {}, byrefRegs=00000006 {rcx rdx}, byref, isz
        ; byrRegs +[rcx rdx]
-       cmp      byte  ptr [rcx], cl
        lea      rsi, bword ptr [rcx+16]
        ; byrRegs +[rsi]
        add      rdx, 16
        mov      edi, dword ptr [rdx]
        vmovsd   xmm0, qword ptr [rdx+8]
        vmovsd   xmm1, qword ptr [rsi+8]
        vucomisd xmm0, xmm1
        jbe      SHORT G_M1099_IG04

[jakobbotsch]

This is a bit more tricky than this because of big offsets, e.g. in the failing test we have IR like

N002 (  2,  2) [000058] ---X-------                         │  ├──▌  NULLCHECK byte  
N001 (  1,  1) [000057] -----------                         │  │  └──▌  LCL_VAR   byref  V01 loc0         u:2
...
N006 (  4,  7) [000063] D--XG--N---                         │  └──▌  IND       int   
N005 (  2,  5) [000061] -------N---                         │     └──▌  ADD       byref 
N003 (  1,  1) [000059] -----------                         │        ├──▌  LCL_VAR   byref  V01 loc0         u:2
N004 (  1,  4) [000060] -----------                         │        └──▌  CNS_INT   long   0x31C2000 field offset Fseq[lastField]
...
N002 (  2,  2) [000065] ---X-------                            ├──▌  NULLCHECK byte  
N001 (  1,  1) [000064] -----------                            │  └──▌  LCL_VAR   byref  V01 loc0         u:2

Today the only thing that prevents us from removing [000058] is the GTF_EXCEPT on [000063]; otherwise we would remove it because of the upcoming 000065. With this change we allow removing it, which is obviously not correct. We could maybe handle it by parsing the offset like in other places in the JIT, but that would be more involved.