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

[Nikita Popov 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);
----------------
nikic wrote:

This means that we're going to also convert ptrtoint from IR into ptrtoaddr, right? That's... maybe not entirely wrong if we say that SCEV just doesn't model the side-effecting part of ptrtoint, but it's pretty iffy. I'd expect SCEV to just start treating ptrtoint as SCEVUnknown instead. Is that possible?

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