[all-commits] [llvm/llvm-project] 21c6c4: [NFC][SCEV] Add tests for umin_seq recognition wit...

[Roman Lebedev via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 21c6c43e6feaf3e9d079c94ee0027e197076c1cf
      https://github.com/llvm/llvm-project/commit/21c6c43e6feaf3e9d079c94ee0027e197076c1cf
  Author: Roman Lebedev <lebedev.ri at gmail.com>
  Date:   2022-02-16 (Wed, 16 Feb 2022)

  Changed paths:
    M llvm/test/Analysis/ScalarEvolution/logical-operations.ll

  Log Message:
  -----------
  [NFC][SCEV] Add tests for umin_seq recognition with interfering zext's


  Commit: 3c7d48ed902a7136a131c1288d75bfcf7af557c6
      https://github.com/llvm/llvm-project/commit/3c7d48ed902a7136a131c1288d75bfcf7af557c6
  Author: Roman Lebedev <lebedev.ri at gmail.com>
  Date:   2022-02-16 (Wed, 16 Feb 2022)

  Changed paths:
    M llvm/lib/Analysis/ScalarEvolution.cpp
    M llvm/test/Analysis/ScalarEvolution/logical-operations.ll

  Log Message:
  -----------
  [NFC][SCEV] Recognize umin_seq when operand is zext'ed in umin but not in zero-check

zext(umin(x,y)) == umin(zext(x),zext(y))
zext(x) == 0  ->  x == 0

Extra leading zeros do not affect the result of comparison with zero,
nor do they matter for the unsigned min/max,
so we should not be dissuaded when we find a zero-extensions,
but instead we should just skip it.


  Commit: ae48af582b34f571fdfb1a05adda0f3bc9fe5569
      https://github.com/llvm/llvm-project/commit/ae48af582b34f571fdfb1a05adda0f3bc9fe5569
  Author: Roman Lebedev <lebedev.ri at gmail.com>
  Date:   2022-02-16 (Wed, 16 Feb 2022)

  Changed paths:
    M llvm/lib/Analysis/ScalarEvolution.cpp
    M llvm/test/Analysis/ScalarEvolution/logical-operations.ll

  Log Message:
  -----------
  [NFC][SCEV] Recognize umin_seq when operand is zext'ed in zero-check

zext(umin(x,y)) == umin(zext(x),zext(y))
zext(x) == 0  ->  x == 0

While it is not a very likely scenario, we probably should not expect
that instcombine already dropped such a redundant zext,
but handle directly. Moreover, perhaps there was no ZExtInst,
and SCEV somehow managed to  pull out said zext out of the SCEV expression.


Compare: https://github.com/llvm/llvm-project/compare/0bad7cb56526...ae48af582b34