[all-commits] [llvm/llvm-project] 9c4baf: [ScalarEvolution] Strictly enforce pointer/int typ...

[Eli Friedman via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 9c4baf5101e9ee55bfae1ce7657a7b89a06b4ccf
      https://github.com/llvm/llvm-project/commit/9c4baf5101e9ee55bfae1ce7657a7b89a06b4ccf
  Author: Eli Friedman <efriedma at quicinc.com>
  Date:   2021-07-09 (Fri, 09 Jul 2021)

  Changed paths:
    M llvm/lib/Analysis/ScalarEvolution.cpp
    M llvm/lib/Transforms/Scalar/LoopStrengthReduce.cpp
    M llvm/lib/Transforms/Utils/ScalarEvolutionExpander.cpp
    M llvm/unittests/Analysis/ScalarEvolutionTest.cpp

  Log Message:
  -----------
  [ScalarEvolution] Strictly enforce pointer/int type rules.

Rules:

1. SCEVUnknown is a pointer if and only if the LLVM IR value is a
   pointer.
2. SCEVPtrToInt is never a pointer.
3. If any other SCEV expression has no pointer operands, the result is
   an integer.
4. If a SCEVAddExpr has exactly one pointer operand, the result is a
   pointer.
5. If a SCEVAddRecExpr's first operand is a pointer, and it has no other
   pointer operands, the result is a pointer.
6. If every operand of a SCEVMinMaxExpr is a pointer, the result is a
   pointer.
7. Otherwise, the SCEV expression is invalid.

I'm not sure how useful rule 6 is in practice.  If we exclude it, we can
guarantee that ScalarEvolution::getPointerBase always returns a
SCEVUnknown, which might be a helpful property. Anyway, I'll leave that
for a followup.

This is basically mop-up at this point; all the changes with significant
functional effects have landed.  Some of the remaining changes could be
split off, but I don't see much point.

Differential Revision: https://reviews.llvm.org/D105510