[llvm] [polly] [SCEV] Use SCEVPtrToAddr instead of SCEVPtrToInt in SCEV. (PR #180244)

[Florian Hahn via llvm-commits]

================
@@ -1155,10 +1116,22 @@ const SCEV *ScalarEvolution::getPtrToAddrExpr(const SCEV *Op) {
 const SCEV *ScalarEvolution::getPtrToIntExpr(const SCEV *Op, Type *Ty) {
   assert(Ty->isIntegerTy() && "Target type must be an integer type!");
 
-  const SCEV *IntOp = getLosslessPtrToIntExpr(Op);
-  if (isa<SCEVCouldNotCompute>(IntOp))
-    return IntOp;
+  // It isn't legal for optimizations to construct new ptrtoint expressions
+  // for non-integral pointers.
+  if (getDataLayout().isNonIntegralPointerType(Op->getType()))
+    return getCouldNotCompute();
+
+  Type *IntPtrTy = getDataLayout().getIntPtrType(Op->getType());
+
+  // We can only trivially model ptrtoint via ptrtoaddr if SCEV's effective
+  // (integer) type is sufficiently wide to represent all possible pointer
+  // values. We could theoretically teach SCEV to truncate wider pointers, but
+  // that isn't implemented for now.
+  if (getDataLayout().getTypeSizeInBits(getEffectiveSCEVType(Op->getType())) !=
+      getDataLayout().getTypeSizeInBits(IntPtrTy))
+    return getCouldNotCompute();
 
+  const SCEV *IntOp = getPtrToAddrExpr(Op);
----------------
fhahn wrote:

Hmm, for the reasoning/modeling in SCEV the side-effect part should not matter, right? Having both SCEVPtrToIntExpr and SCEVPtrToAddr expressions would require in some cases that we treat ptrtoint and ptrtoaddr of the same pointers as equivalent or loose some simplifications (or need to keep `SCEVPtrToAddrRewrite`)

https://github.com/llvm/llvm-project/pull/180244