[RyuJIT][ARM] Redundant overflow check in "C / X"

[EgorBo]

int Test(int a) => 1000 / b; // same for 'C % b'

Current arm64 codegen:

G_M17171_IG01: 
        A9BF7BFD          stp     fp, lr, [sp,#-16]!
        910003FD          mov     fp, sp
G_M17171_IG02:       
        52807D00          mov     w0, #0x3e8
        7100005F          cmp     w2, #0
        54000140          beq     G_M17171_IG06
        3100045F          cmn     w2, #1
        54000081          bne     G_M17171_IG03
        2B00001F          adds    wzr, w0, w0
        54000041          bne     G_M17171_IG03 ; <-- btw, two subsequent jumps?? 
        54000086          bvs     G_M17171_IG05
G_M17171_IG03:       
        1AC20C00          sdiv    w0, w0, w2
G_M17171_IG04:       
        A8C17BFD          ldp     fp, lr, [sp],#16
        D65F03C0          ret     lr
G_M17171_IG05:           
        94000000          bl      CORINFO_HELP_OVERFLOW
G_M17171_IG06:            
        94000000          bl      CORINFO_HELP_THROWDIVZERO
        D43E0000          bkpt
; Total bytes of code 64

As far as I understand overflow can only happen if we divide int.MinValue by -1 so it's not the case for C / x where C is not int.MinValue

Also, GT_ARRLEN can't be -1 and int.MinValue so e.g. array.Length % x or x % array.Length shouldn't produce any overflow checks as well.

category:cq
theme:div-mod-rem
skill-level:intermediate
cost:medium
impact:medium

[echesakov]

Un-assigning myself
cc @BruceForstall

[a74nh]

@TIHan are you actively looking at this? Otherwise could we assign it to @SwapnilGaikwad

[TIHan]

I marked it as future, but if you all want to look at it that is fine with me. If you have any questions, I am happy to answer.

[SwapnilGaikwad]

That's great. I'll take a look then.

[a74nh]

As far as I understand overflow can only happen if we divide int.MinValue by -1 so it's not the case for C / x where C is not int.MinValue

This part was fixed by #75272

Also, GT_ARRLEN can't be -1 and int.MinValue so e.g. array.Length % x or x % array.Length shouldn't produce any overflow checks as well.

This part is a much bigger fix. After the CIL has been parsed into IR, the array.Length has been turned into an indirect load, and there is nothing to indicate that it's different to any other indirect load. You would need to add something into the IR to indicate the value is >=0 during parsing.

#64795 is a similar at first glance, but it doesn't really overlap with this.

My thought would be to solve this with a new gtFlag entry. You could have GT_IS_GE_0 and GT_IS_GT_0. Both of these could then be used in other optimisations eg: to get rid of some comparisons.

However, I'm not sure how many other places we can guarantee that a value is >0 or >=0. If it's small, then I doubt the work here is worthwhile.