On Dec 9, 2007, at 2:57 PM, Wojciech Matyjewicz wrote: > 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.
Ok. > I guess, such a large positive index in GEP as seen above can be > introduced by -instcombine pass. Ok. This is somewhat dubious though, as it is wrapping around the end of the address space which is undefined in C. > 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. Ah, that does make a lot of sense. Since the fix is simple, please go for it! -Chris _______________________________________________ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
