Tree aliasing

Tree aliasing

[Andrew Pinski]

I was improving tree aliasing for pointers by adding support a+1 and a
not aliasing.  But I ran into a bug in the aliasing where:
  /* If both references are through the same type, they do not alias
     if the accesses do not overlap.  This does extra disambiguation
     for mixed/pointer accesses but requires strict aliasing.  */
  if (same_type_for_tbaa (TREE_TYPE (TREE_TYPE (ptr1)),
                          TREE_TYPE (TREE_TYPE (ptr2))) == 1)
    return ranges_overlap_p (offset1, max_size1, offset2, max_size2);

Would return false even.  I can't see how this can be true if one
pointer is defined as an offset as the other and the offset1 or
offset2 are non zero.

Can someone explain why this is true?

Even nonaliasing_component_refs_p looks to have the same issue if the
types are the same, they could be an extra offset from each other,
even though the compiler cannot figure that out.  I am thinking of
when storing the pointer in an array and then accessing that pointer.

gcc.dg/20030324-1.c is the testcase where I am running into this bug too.

Thanks,
Andrew Pinski

Re: Tree aliasing

[Richard Guenther]

On Tue, Aug 4, 2009 at 4:25 AM, Andrew Pinski<pinskia@gmail.com> wrote:
> I was improving tree aliasing for pointers by adding support a+1 and a
> not aliasing.  But I ran into a bug in the aliasing where:
>  /* If both references are through the same type, they do not alias
>     if the accesses do not overlap.  This does extra disambiguation
>     for mixed/pointer accesses but requires strict aliasing.  */
>  if (same_type_for_tbaa (TREE_TYPE (TREE_TYPE (ptr1)),
>                          TREE_TYPE (TREE_TYPE (ptr2))) == 1)
>    return ranges_overlap_p (offset1, max_size1, offset2, max_size2);
>
> Would return false even.  I can't see how this can be true if one
> pointer is defined as an offset as the other and the offset1 or
> offset2 are non zero.
>
> Can someone explain why this is true?

This is true because if you have two pointers pointing to the indentical
type T then with strict-aliasing you either have a full overlap
(ptr1 == ptr2) or no overlap.  I can see one mistake here in that
the offsets (I need to think about the max-sizes) need to be modulo
the size of the pointed-to type, but
other than that it's ok.  A fix for that is appreciated (together with
a testcase of course).

Richard.

> Even nonaliasing_component_refs_p looks to have the same issue if the
> types are the same, they could be an extra offset from each other,
> even though the compiler cannot figure that out.  I am thinking of
> when storing the pointer in an array and then accessing that pointer.
>
> gcc.dg/20030324-1.c is the testcase where I am running into this bug too.
>
> Thanks,
> Andrew Pinski
>