Wrong value for sext i1 true in BasicAliasAnalysis

Andrew Trick atrick at apple.com
Fri Dec 19 16:58:13 PST 2014


> On Dec 19, 2014, at 4:43 AM, Nicholas White <n.j.white at gmail.com> wrote:
> 
> > you just have to formulate your solution in terms of these facts:
> 
> Thanks - that helps a lot. I've updated http://reviews.llvm.org/D6682 <http://reviews.llvm.org/D6682> to use this, and the patch passes most of the BasicAA regression tests now. I've narrowed down the failures to the test case @based_on_pr18068 in the commit (reproduced below); basically it doesn't know that zext(%var + 1) != zext(%var) for all values of %var when the addition doesn't have the NUW flag set. As %var + 1 may wrap we can't decompose it into zext(%var) + zext(1) - i.e. if we tried to decompose zext(%var + 1) into zext(%var) + C then C could either be +1 or -zext(%var). As the current logic stores the offset in APInt it clearly can't deal with this situation. I'm thinking of allowing the offset to be a dummy unknown-but-non-zero number as well as an APInt, as this would cover the remaining cases. Thanks -

Sure, you basically want some flag to indicate that the expression doesn't fully wrap back to the original value.

As far as your current patch goes, this looks like the right idea. There are a few things I'm unsure of...

I think the vector of Extensions is confusing. If you only handle extension to a pointer-width, then you only need to remeber the last seen extension as you recurse upward.

For example, if all operations are nsw/nuw:
sext64(c1 + zext64(c2 + v)) => sext64(c1) + zext64(c2) + zext64(v)

That's because sext64(zext64(v)) == zext64(v)

If you're only handling extension to a pointer-width, only one extension can possible matter. I think handling extensions and truncations to/from arbitrary width would be way too complicated.

The places where you're zero-extending APInt are confusing to me. Why is this safe? Is it because you don’t actually care whether one index is greater or less than another, just that their difference is nonzero? Can you explain with comments?

+ Offset += Const->getValue().zextOrSelf(Offset.getBitWidth());

Andy

PS: I’ll be away for a couple weeks, but I’m fine if someone else signs off on the patch.

> 
> Nick
> 
> ; CHECK-LABEL: based_on_pr18068
> ; CHECK: NoAlias: i8* %a, i8* %b
> define void @based_on_pr18068(i32 %loaded, i8* %mem) {
>   %loaded.64 = zext i32 %loaded to i64
>   %add1 = add i32 %loaded, 1 ; unsigned wraps iff %loaded == 0xFFFFFFFF
>   %add1.64 = zext i32 %add1 to i64 ; is zext(%loaded) always != zext(%loaded + 1)? Yes -> NoAlias
>   %a = getelementptr inbounds i8* %mem, i64 %loaded.64
>   %b = getelementptr inbounds i8* %mem, i64 %add1.64
>   ret void
> }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141219/8b731e0c/attachment.html>


More information about the llvm-commits mailing list