Wrong value for sext i1 true in BasicAliasAnalysis

[Nicholas White]

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

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/9ff31b55/attachment.html>