[all-commits] [llvm/llvm-project] 17cec6: Revert 1c021c64c "[SCEV] Model ptrtoint(SCEVUnknow...

[Hans via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 17cec6a11a12f815052d56a17ef738cf246a2d9a
      https://github.com/llvm/llvm-project/commit/17cec6a11a12f815052d56a17ef738cf246a2d9a
  Author: Hans Wennborg <hans at chromium.org>
  Date:   2020-10-12 (Mon, 12 Oct 2020)

  Changed paths:
    M llvm/lib/Analysis/ScalarEvolution.cpp
    M llvm/lib/Transforms/Utils/SimplifyIndVar.cpp
    M llvm/test/Analysis/ScalarEvolution/add-expr-pointer-operand-sorting.ll
    M llvm/test/Analysis/ScalarEvolution/no-wrap-add-exprs.ll
    M llvm/test/Analysis/ScalarEvolution/ptrtoint.ll
    M llvm/test/CodeGen/ARM/lsr-undef-in-binop.ll
    M llvm/test/CodeGen/X86/ragreedy-hoist-spill.ll
    M llvm/test/Transforms/IndVarSimplify/2011-11-01-lftrptr.ll
    M polly/test/Isl/CodeGen/scev_looking_through_bitcasts.ll

  Log Message:
  -----------
  Revert 1c021c64c "[SCEV] Model ptrtoint(SCEVUnknown) cast not as unknown, but as zext/trunc/self of SCEVUnknown"

> While we indeed can't treat them as no-ops, i believe we can/should
> do better than just modelling them as `unknown`. `inttoptr` story
> is complicated, but for `ptrtoint`, it seems straight-forward
> to model it just as a zext-or-trunc of unknown.
>
> This may be important now that we track towards
> making inttoptr/ptrtoint casts not no-op,
> and towards preventing folding them into loads/etc
> (see D88979/D88789/D88788)
>
> Reviewed By: mkazantsev
>
> Differential Revision: https://reviews.llvm.org/D88806

It caused the following assert during Chromium builds:

  llvm/lib/IR/Constants.cpp:1868:
  static llvm::Constant *llvm::ConstantExpr::getTrunc(llvm::Constant *, llvm::Type *, bool):
  Assertion `C->getType()->isIntOrIntVectorTy() && "Trunc operand must be integer"' failed.

See code review for a link to a reproducer.

This reverts commit 1c021c64caef83cccb719c9bf0a2554faa6563af.