[PATCH] D106099: [DependenceAnalysis] Guard analysis using getPointerBase()

Eli Friedman via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Jul 15 15:10:44 PDT 2021


efriedma added inline comments.


================
Comment at: llvm/lib/Analysis/DependenceAnalysis.cpp:3556
   LLVM_DEBUG(dbgs() << "    DstSCEV = " << *DstSCEV << "\n");
+  if (SE->getPointerBase(SrcSCEV) != SE->getPointerBase(DstSCEV)) {
+    // If two pointers have different bases, trying to analyze indexes won't
----------------
bmahjour wrote:
> We only get here if the two pointers `MustAlias`.  If my understanding of `MustAlias` is correct (that it means precise and complete overlapping of memory), and if the two references are in the same loop, then comparing indexes seems reasonable. In that case, the effect of the following analysis should be as if `src` and `dst` SCEVs have their base pointers replaced with the same value. Not sure what's the best way to deal with such cases. Does it make sense to introduce a mode in `getMinusSCEV` where different base pointers can be permitted? 
`underlyingObjectsAlias(Src, Dst) == MustAlias` is basically a slightly fancier version `isIdentifiedObject(getUnderlyingObject(Src)) && isIdentifiedObject(getUnderlyingObject(Dst)) && getUnderlyingObject(Src) == getUnderlyingObject(Dst)`.  The issue here is that getPointerBase() is less powerful than getUnderlyingObject().

It is possible to cast the operands of getMinusSCEV to integers using getPtrToIntExpr(); in that case, you won't get a SCEVCouldNotCompute.  But then you end up with a SCEV containing something like `ptrtoint(SrcSCEVPointerBase) - ptrtoint(DstSCEVPointerBase)`, which is basically impossible to analyze.  So it seems simpler to just reject early.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D106099/new/

https://reviews.llvm.org/D106099



More information about the llvm-commits mailing list