[LLVMdev] Basic AliasAnalysis: Can GEPs with the same base but different constant indices into a struct alias?

[Ahmed Bougacha]

On Mon, Feb 2, 2015 at 10:59 AM, Chandler Carruth <chandlerc at google.com>
wrote:

>
> On Mon, Feb 2, 2015 at 10:55 AM, Ahmed Bougacha <ahmed.bougacha at gmail.com>
> wrote:
>
>> Ah yes, the structs are what make it messy.
>>
>> How about the more useful constraint:
>> - the (identical) base must point to a (possibly multidimensional) array
>> of structs.
>>
>> Then, the above holds, no?  No matter which path you take, you must point
>> to a one of the contiguous structs, and if the index is different then the
>> pointers can't alias.
>>
>
> I don't really know what you're proposing.  However, note that I can nest
> arrays inside of structs and wrap structs in arrays, so I think I can
> essentially almost always arrange to have arrays which I can overflow to
> produce aliasing offsets.
>

But that doesn't matter, no?  If AA is looking at two GEPs indexing into
say [1 x {[0 x i32], i32}]:
- we can state that gep 0, 0, 0 and gep 0, 0, 1 don't alias
- even though gep 0, 0, 0, 1 and gep 0, 0, 1 can, since this is a different
query.

So if you have say [1 x {i32, i32}], you can safely say that gep 0, i, 0
and gep 0, j, 1 can't alias.

Or maybe this is my core misunderstanding of the problem?


> What are you really trying to achieve here? Why is just modeling the math
> not sufficient here?
>

See the originally attached testcase, where the load seems redundant, but
we can't prove the two GEPs don't alias.

-Ahmed


> Anyway, the help is much appreciated, thanks Chandler & Hal!
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150202/62439cb7/attachment.html>