[PATCH] D38662: [BasicAA] Support arbitrary pointer sizes (and fix an overflow bug)

[Eli Friedman via Phabricator via llvm-commits]

efriedma added inline comments.


================
Comment at: lib/Analysis/BasicAliasAnalysis.cpp:519
+      // relevant values of V, (C2*Scale) can overflow. In that case, we cannot
+      // decompose the expression in this way.
+      APInt WideScaledOffset = IndexOffset.sextOrTrunc(MaxPointerSize*2) *
----------------
hfinkel wrote:
> efriedma wrote:
> > I'm not sure I understand this comment.
> > 
> > It's true that C2*Scale can overflow, but I'm not sure it makes sense to try to address that here.  The multiply by the scale can overflow no matter where the scale comes from (assuming the GEP isn't marked inbounds).
> Can you please elaborate?
> 
> If this overflows, then the offset here isn't an offset, and the reasoning done later won't be correct.
> 
> In the test case, the GEPs are marked as inbounds. I don't think that's relevant here.
Consider the following testcase:

```
target datalayout = "e-m:e-p:32:32-f64:32:64-f80:32-n8:16:32-S128"
define i32* @b1(i32 *%a) {
%r = getelementptr i32, i32* %a, i32 -2147483648
ret i32* %r
}
define i32* @b2(i32 *%a) {
%o = add i32 -2147483648, 0
%r = getelementptr i32, i32* %a, i32 %o
ret i32* %r
}
```

In both cases, %a and %r should be mustalias.  If you run "-aa-eval", we somehow conclude that the pointers are mustalias in b1, and noalias in b2.   If you're trying to make overflow well-behaved, it doesn't make sense to treat the overflow introduced by GetLinearExpression differently from the overflow inherent in scaling.


https://reviews.llvm.org/D38662