Wrong value for sext i1 true in BasicAliasAnalysis

[Nicholas White]

> That's because sext64(zext64(v)) == zext64(v)
> sext(zext(y)) is not interesting because the sign bit is known to be zero
Ach, I missed this! This means a VariableGEPIndex only needs two counters,
one for the number of bits SExt'ed and one for the number of bits ZExt'ed -
and the ExtensionKind enum can be removed entirely. I've updated
http://reviews.llvm.org/D6682 - it's much cleaner (+174,-57 plus tests) now.

> How are you getting a MustAlias?
Hm, I can't reproduce this. On stepping through that example in a build of
3f2027522c83fcb4fd8629b6395cec82bfda9cd1 it seems the PartialAlias decision
comes because GetLinearExpression doesn't look through the two sext
instructions (%sext.1 and %sext.2), so GetIndexDifference doesn't cancel
the two expressions out. This means that it doesn't decide that %a and %b
NoAlias in the below:

define void @test_zext_sext_amounts255(i8* %mem) {
  %sext.1 = sext i8 255 to i16
  %sext.zext.1 = zext i16 %sext.1 to i64
  %sext.2 = sext i8 255 to i32
  %sext.zext.2 = zext i32 %sext.2 to i64
  %a = getelementptr inbounds i8* %mem, i64 %sext.zext.1
  %b = getelementptr inbounds i8* %mem, i64 %sext.zext.2
  ret void
}

.> Expecting it to work just as well on un-optimized IR is not reasonable.
OK, that makes sense.

Thanks -

Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141223/ff923b2b/attachment.html>