[llvm-commits] RFC: patch for PR1782 (BasicAliasAnalyis)

[Chris Lattner]

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