[all-commits] [llvm/llvm-project] 7b16fd: [NFC][CVP] Add tests for possible sdiv->udiv where...

[Roman Lebedev via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 7b16fd8a2514287765cdcdb09b9059d5d9a2933a
      https://github.com/llvm/llvm-project/commit/7b16fd8a2514287765cdcdb09b9059d5d9a2933a
  Author: Roman Lebedev <lebedev.ri at gmail.com>
  Date:   2020-07-18 (Sat, 18 Jul 2020)

  Changed paths:
    M llvm/test/Transforms/CorrelatedValuePropagation/sdiv.ll

  Log Message:
  -----------
  [NFC][CVP] Add tests for possible sdiv->udiv where operands are not non-negative

Currently that fold requires both operands to be non-negative,
but the only real requirement for the fold is that we must know
the domains of the operands.


  Commit: 2cde6984d8fbaf9d3ce9e09ce632f7de553df5bb
      https://github.com/llvm/llvm-project/commit/2cde6984d8fbaf9d3ce9e09ce632f7de553df5bb
  Author: Roman Lebedev <lebedev.ri at gmail.com>
  Date:   2020-07-18 (Sat, 18 Jul 2020)

  Changed paths:
    M llvm/lib/Transforms/Scalar/CorrelatedValuePropagation.cpp

  Log Message:
  -----------
  [NFC][CVP] Refactor isPositive() out of hasPositiveOperands()


  Commit: 45b738882474e615ccf15e289b765bca0ccfc1d2
      https://github.com/llvm/llvm-project/commit/45b738882474e615ccf15e289b765bca0ccfc1d2
  Author: Roman Lebedev <lebedev.ri at gmail.com>
  Date:   2020-07-18 (Sat, 18 Jul 2020)

  Changed paths:
    M llvm/lib/Transforms/Scalar/CorrelatedValuePropagation.cpp

  Log Message:
  -----------
  [NFC][CVP] Rename predicates - s/positive/non negative/ to better note that zero is ok


  Commit: 8d487668d09fb0e4e54f36207f07c1480ffabbfd
      https://github.com/llvm/llvm-project/commit/8d487668d09fb0e4e54f36207f07c1480ffabbfd
  Author: Roman Lebedev <lebedev.ri at gmail.com>
  Date:   2020-07-18 (Sat, 18 Jul 2020)

  Changed paths:
    M llvm/lib/Transforms/Scalar/CorrelatedValuePropagation.cpp
    M llvm/test/Transforms/CorrelatedValuePropagation/sdiv.ll

  Log Message:
  -----------
  [CVP] Soften SDiv into a UDiv as long as we know domains of both of the operands.

Yes, if operands are non-positive this comes at the extra cost
of two extra negations. But  a. division is already just
ridiculously costly, two more subtractions can't hurt much :)
and  b. we have better/more analyzes/folds for an unsigned division,
we could end up narrowing it's bitwidth, converting it to lshr, etc.

This is essentially a take two on 0fdcca07ad2c0bdc2cdd40ba638109926f4f513b,
which didn't fix the potential regression i was seeing,
because ValueTracking's computeKnownBits() doesn't make use
of dominating conditions in it's analysis.
While i could teach it that, this seems like the more general fix.

This big hammer actually does catch said potential regression.

Over vanilla test-suite + RawSpeed + darktable
(10M IR instrs, 1M IR BB, 1M X86 ASM instrs), this fires/converts 5 more
(+2%) SDiv's, the total instruction count at the end of middle-end pipeline
is only +6, so out of +10 extra negations, ~half are folded away,
and asm instr count is only +1, so practically speaking all extra
negations are folded away and are therefore free.
Sadly, all these new UDiv's remained, none folded away.
But there are two less basic blocks.

https://rise4fun.com/Alive/VS6

Name: v0
Pre: C0 >= 0 && C1 >= 0
%r = sdiv i8 C0, C1
  =>
%r = udiv i8 C0, C1

Name: v1
Pre: C0 <= 0 && C1 >= 0
%r = sdiv i8 C0, C1
  =>
%t0 = udiv i8 -C0, C1
%r = sub i8 0, %t0

Name: v2
Pre: C0 >= 0 && C1 <= 0
%r = sdiv i8 C0, C1
  =>
%t0 = udiv i8 C0, -C1
%r = sub i8 0, %t0

Name: v3
Pre: C0 <= 0 && C1 <= 0
%r = sdiv i8 C0, C1
  =>
%r = udiv i8 -C0, -C1


Compare: https://github.com/llvm/llvm-project/compare/c73df5696696...8d487668d09f