[optimization] gcc generate better code than clang base on value range propagation

[vfdff]

• test case:
  int my_abs (int x, int y) { return x>y ? abs (x-y) + y: 0; }
• clang's code, which need more optimization

my_abs: // @my_abs
  subs w8, w0, w1
  b.le .LBB0_2
  cmp w8, #0
  cneg w8, w8, mi
  add w0, w8, w1
  ret
.LBB0_2:
  mov w0, wzr
  ret

Compared to gcc, clang produces slightly more verbose code for a sequence, see detail https://godbolt.org/z/en7Mqcd7v

[llvmbot]

@llvm/issue-subscribers-backend-aarch64

[peterwaller-arm]

For AArch64 it looks like there is an additional issue complicating this. The cost to speculate the abs is currently reported as 3, so it doesn't eliminate the branch. AArch64 generates a cmp+cneg for abs, cheaper than the generic cost from BasicTTImpl. Fixing this allows simplifycfg to eliminate the branch.

From there LLVM needs to be able to achieve the following, noticing that condition of the inner select is already constrained by the outer condition (except not on a select, but an abs intrinsic). My brief look at this ends here for now.

(select (x > y) (y + (select (x - y > 0) (x - y) (y - x))) 0)
=> (select (x > y) (y + (x - y)) 0)
=> (select (x > y) x 0)

Edit: scratching out the above as it is misleading. The fix is not to eliminate the branch, but to fix the combine under the condition {abs(x-y) | x >= y} => x-y, which with the ...+y, optimizes to just x, which bcl5980 is doing here: https://reviews.llvm.org/D122013

[vfdff]

Thanks very much for your introduce

[vfdff]

clang slightly worse than gcc on case my_abs4 : https://godbolt.org/z/oK1fxqEeb