[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:

> Hmmm I see. Do you know where we potentially have such re-writes?

I'd expect this can happen with the indvars exit value rewrite for example, in cases where the exit value contains a ptrtoint expressions.

> Yeah one issue is when we have sub of ptrtoint vs sub of ptrtoaddr when we create SCEVs for a loop trip count and try to reason about them, e.g. for dereferenceable assumptions. sub of ptrtoint is unfortunately quite common, e.g. for loops over libc++'s std::vector.
> 
> I am not really sure what the best way forward is. Maybe somehow try to convert to ptrtoaddr for reasoning, but prevent using it for expansion somehow?

If we added a special case specifically to treat "sub of ptrtoint" the same as "sub to ptrtoaddr" in SCEV, would that be good enough? I'd be more comfortable with a carve-out like that, as I'd expect we'd be able to remove it in the future once we change how pointer subtractions are lowered by clang.

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