Issue Description:

Consider the following:

func test(_ front: inout Int8, _ n: Int8) {
    if front > n, n >= 0 {
      front -= n
    }
}

There is no combination of values which can cause to "front -= n" to fail with overflow. I've used Int8 here because it's simple to test it exhaustively, but the same applies to Int:

 for f in Int8.min...Int8.max {
      for n in Int8.min...Int8.max {
        var front = f
        test(&front, n) // Does not trap
      }
    }

Unfortunately, Swift (latest nightly, -O) is unable to eliminate these simple traps:

output.test(inout Swift.Int8, Swift.Int8) -> ():
        test    sil, sil
        js      .LBB1_4
        mov     al, byte ptr [rdi]
        sub     al, sil
        jle     .LBB1_4
        jo      .LBB1_5
        mov     byte ptr [rdi], al
.LBB1_4:
        ret
.LBB1_5:
        ud2

Godbolt

This ends up having a huge impact on performance, meaning that in most cases, the onus falls on the user to prove overflow is impossible and use non-trapping arithmetic. The compiler should do a better job of automating that.

This is probably more of an LLVM deficiency, but it hits us hard due to the prevalence of signed integers and bounds-checking.