[all-commits] [llvm/llvm-project] a09b5a: [NFC][SCEV] Reflow `GetMinTrailingZerosImpl()` int...

[Roman Lebedev via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: a09b5a0cfcbd7a1e7239f36c1cfd815c3ed19220
      https://github.com/llvm/llvm-project/commit/a09b5a0cfcbd7a1e7239f36c1cfd815c3ed19220
  Author: Roman Lebedev <lebedev.ri at gmail.com>
  Date:   2023-01-22 (Sun, 22 Jan 2023)

  Changed paths:
    M llvm/lib/Analysis/ScalarEvolution.cpp

  Log Message:
  -----------
  [NFC][SCEV] Reflow `GetMinTrailingZerosImpl()` into an exhaustive switch


  Commit: 42aaab3b4545534e41da56961f9b62aa8af771c9
      https://github.com/llvm/llvm-project/commit/42aaab3b4545534e41da56961f9b62aa8af771c9
  Author: Roman Lebedev <lebedev.ri at gmail.com>
  Date:   2023-01-22 (Sun, 22 Jan 2023)

  Changed paths:
    M llvm/lib/Analysis/ScalarEvolution.cpp

  Log Message:
  -----------
  [NFC][SCEV] `GetMinTrailingZerosImpl()`: deduplicate handling

`scPtrToInt` recieves same treatment as normal n-ary ops.


  Commit: 4f9f0b480fbcbfafa3805e5a7ff319546a30780e
      https://github.com/llvm/llvm-project/commit/4f9f0b480fbcbfafa3805e5a7ff319546a30780e
  Author: Roman Lebedev <lebedev.ri at gmail.com>
  Date:   2023-01-22 (Sun, 22 Jan 2023)

  Changed paths:
    M llvm/lib/Analysis/ScalarEvolution.cpp

  Log Message:
  -----------
  [NFC][SCEV] Reflow `getRangeRefIter()` into an exhaustive switch

And, this shows a bug in the original code:
why do we not recurse into casts?

If i add an assertion that those opcodes are never encountered,
the assertion fails in a number of existing tests.


  Commit: 0cdf030cf8dcfb8bfe551c16b14a29e124497069
      https://github.com/llvm/llvm-project/commit/0cdf030cf8dcfb8bfe551c16b14a29e124497069
  Author: Roman Lebedev <lebedev.ri at gmail.com>
  Date:   2023-01-22 (Sun, 22 Jan 2023)

  Changed paths:
    M llvm/lib/Analysis/ScalarEvolution.cpp

  Log Message:
  -----------
  [SCEV] `getRangeRefIter()`: don't forget to recurse into casts

I'm not really sure the problem can be nicely exposed via a lit test,
since we don't give up on range calculation for deeply nested ranges,
but if i add an assertion that those opcodes are never encountered,
the assertion fails in a number of existing tests.

In reality, the iterative approach is still pretty partial:
1. `Seen` should not be there. We want the last instance of expression, not the first one
2. There should be a check that `getRangeRefIter()` does not self-recurse


Compare: https://github.com/llvm/llvm-project/compare/31d46ca8aa07...0cdf030cf8dc