Chris Lattner wrote:
> Yep, it looks Gordon was right :). Thanks again Wojtek, I applied the
> patch. Please close the PR,
Before I close the PR, I would like to discuss one more issue discovered
while working on it.
Suppose, we have a target with 32-bit pointers and the following
instructions:
%p = getelementptr i32* %x, i32 -1
%q = getelementptr i32* %x, i32 1073741823 ;(1073741823 == 2^30 - 1)
TargetData::getIndexedOffset() uses 64-bit arithmetic to perform offset
computation and return 64-bit values. Hence, it will return -4 as an
offset for %p, and 2^32 - 4 for %q. Based on these offsets, it may seem
that %p and %q point to different memory objects. However, they don't,
taking into account that pointers are 32-bit long.
I guess, such a large positive index in GEP as seen above can be
introduced by -instcombine pass.
BasicAA seems to be affected by the issue. For the attached example opt
-aa-eval says that %p and %q don't alias.
I think, the simplest way to fix it is to truncate the computed offset
to the target pointer size before returning it in
TargetData::getIndexedOffset(). If you think this is the correct
approach, I may prepare a patch.
-Wojtek
target datalayout =
"e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32"
define void @foo(i32* %x) {
entry:
%p = getelementptr i32* %x, i32 -1
%q = getelementptr i32* %x, i32 1073741823
ret void
}
_______________________________________________
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
