[X86] Missed combining of usubo+cmp into sbb

[chfast]

This is implementation of less-than of 2x i64 multi-precision integer done by checking the carry flag from subtraction.
https://godbolt.org/z/Kbhnq8c91

define i1 @subcarry_ult_2x64(i64 %x0, i64 %x1, i64 %y0, i64 %y1) nounwind {
  %b0 = icmp ult i64 %x0, %y0
  %d1 = sub i64 %x1, %y1
  %b10 = icmp ult i64 %x1, %y1
  %b0z = zext i1 %b0 to i64
  %b11 = icmp ult i64 %d1, %b0z
  %b1 = or i1 %b10, %b11
  ret i1 %b1
}

Output:

subcarry_ult_2x64:
        sub     rsi, rcx
        setb    cl
        cmp     rdi, rdx
        sbb     rsi, 0
        setb    al
        or      al, cl
        ret

Expected:

subcarry_ult_2x64:
        cmp     rdi, rdx
        sbb     rsi, rcx
        setb    al
        retq

[llvmbot]

@llvm/issue-subscribers-backend-x86

[RKSimon]

https://reviews.llvm.org/D125642 improves the codegen to:

subcarry_ult_2x64:
    subq %rcx, %rsi
    setb %cl
    cmpq %rdx, %rdi
    sbbq $0, %rsi
    setb %al
    orb %cl, %al
    retq

[RKSimon]

@chfast where did this code snippet originally come from? I'm not sure whether its better trying to recognise that this is a i128 comparison in InstCombine or just continue with backend combines (the remaining pattern is very specific).

@rotateright I'm not sure if we do much to reconstruct wider arithmetic in IR? Although there does appear to be this: https://reviews.llvm.org/D101232

[RKSimon]

Alive2: https://alive2.llvm.org/ce/z/7gtizV

The increase in instructions suggests trying to widen the icmp in InstCombine might not be a good idea :(

----------------------------------------
define i1 @src(i8 %x0, i8 %x1, i8 %y0, i8 %y1) {
%0:
  %b0 = icmp ult i8 %x0, %y0
  %d1 = sub i8 %x1, %y1
  %b10 = icmp ult i8 %x1, %y1
  %b0z = zext i1 %b0 to i8
  %b11 = icmp ult i8 %d1, %b0z
  %b1 = or i1 %b10, %b11
  ret i1 %b1
}
=>
define i1 @tgt(i8 %x0, i8 %x1, i8 %y0, i8 %y1) {
%0:
  %xlo = zext i8 %x0 to i16
  %x1z = zext i8 %x1 to i16
  %ylo = zext i8 %y0 to i16
  %y1z = zext i8 %y1 to i16
  %xhi = shl i16 %x1z, 8
  %yhi = shl i16 %y1z, 8
  %x = or i16 %xhi, %xlo
  %y = or i16 %yhi, %ylo
  %b = icmp ult i16 %x, %y
  ret i1 %b
}
Transformation seems to be correct!

[chfast]

@chfast where did this code snippet originally come from? I'm not sure whether its better trying to recognise that this is a i128 comparison in InstCombine or just continue with backend combines (the remaining pattern is very specific).

I have an library implementing uint256 and uint128. In case of uint128 < uint128 compilers are not doing great so I'm falling back to unsigned __int128 if available. I just report some outstanding cases to improve LLVM long term.

I once tried to widen multiplication with mixed results: https://reviews.llvm.org/D56277.

[rotateright]

We're actually missing a reduce of the IR in the example with the subtract, so that makes it even less likely that we'd try widening in instcombine:
https://alive2.llvm.org/ce/z/DJW345

define i1 @src(i8 %x0, i8 %x1, i8 %y0, i8 %y1) {
  %b0 = icmp ult i8 %x0, %y0
  %b0z = zext i1 %b0 to i8
  %d1 = sub i8 %x1, %y1
  %b11 = icmp ult i8 %d1, %b0z
  ret i1 %b11
}

define i1 @tgt(i8 %x0, i8 %x1, i8 %y0, i8 %y1) {
  %b0 = icmp ult i8 %x0, %y0
  %d1 = icmp eq i8 %x1, %y1
  %b11 = and i1 %d1, %b0
  ret i1 %b11
}

[rotateright]

I'm not sure if that makes it easier to widen in the backend, but that fold in IR does seem to slightly improve the x86 asm:
https://alive2.llvm.org/ce/z/PiFs3Y

[chfast]

I updated the output which is a bit better now, but still not the ideal.