<div dir="ltr"><div>> you just have to formulate your solution in terms of these facts:<br><br></div>Thanks - that helps a lot. I've updated <a href="http://reviews.llvm.org/D6682">http://reviews.llvm.org/D6682</a> 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 -<br><br>Nick<br><br>; CHECK-LABEL: based_on_pr18068<br>; CHECK: NoAlias: i8* %a, i8* %b<br>define void @based_on_pr18068(i32 %loaded, i8* %mem) {<br>  %loaded.64 = zext i32 %loaded to i64<br>  %add1 = add i32 %loaded, 1 ; unsigned wraps iff %loaded == 0xFFFFFFFF<br>  %add1.64 = zext i32 %add1 to i64 ; is zext(%loaded) always != zext(%loaded + 1)? Yes -> NoAlias<br>  %a = getelementptr inbounds i8* %mem, i64 %loaded.64<br>  %b = getelementptr inbounds i8* %mem, i64 %add1.64<br>  ret void<br>}<br></div>