[all-commits] [llvm/llvm-project] fdaf30: [NFC][ScalarEvolution] Fix SCEVNAryExpr::getType().

[Eli Friedman via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: fdaf304e0d984c9f919c6b6b2b108d0d31cbea87
      https://github.com/llvm/llvm-project/commit/fdaf304e0d984c9f919c6b6b2b108d0d31cbea87
  Author: Eli Friedman <efriedma at quicinc.com>
  Date:   2021-06-23 (Wed, 23 Jun 2021)

  Changed paths:
    M llvm/include/llvm/Analysis/ScalarEvolutionExpressions.h
    M llvm/lib/Analysis/ScalarEvolution.cpp

  Log Message:
  -----------
  [NFC][ScalarEvolution] Fix SCEVNAryExpr::getType().

SCEVNAryExpr::getType() could return the wrong type for a SCEVAddExpr.
Remove it, and add getType() methods to the relevant subclasses.

NFC because nothing uses it directly, as far as I know; this is just
future-proofing.


  Commit: b12192f7cd8c12898c161c573aad41ac65721c80
      https://github.com/llvm/llvm-project/commit/b12192f7cd8c12898c161c573aad41ac65721c80
  Author: Eli Friedman <efriedma at quicinc.com>
  Date:   2021-06-23 (Wed, 23 Jun 2021)

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

  Log Message:
  -----------
  [ScalarEvolution] Clarify implementation of getPointerBase().

getPointerBase should only be looking through Add and AddRec
expressions; other expressions either aren't pointers, or can't be
looked through.

Technically, this is a functional change. For a multiply or min/max
expression, if they have exactly one pointer operand, and that operand
is the first operand, the behavior here changes. Similarly, if an AddRec
has a pointer-type step, the behavior changes. But that shouldn't be
happening in practice, and we plan to make such expressions illegal.


Compare: https://github.com/llvm/llvm-project/compare/9e73f7c8d2d7...b12192f7cd8c