Re: Aliasing of arrays

[Richard Biener]

On Wed, Nov 30, 2016 at 6:29 PM, Joseph Myers  wrote:
> On Wed, 30 Nov 2016, Richard Biener wrote:
>
>> but that probably shouldn't apply to array types.  The idea is that
>> objects of the same type cannot overlap.  Maybe Joseph can clarify whether
>> and array object of known size really constitutes an object in that sense.
>
> This is one of the ambiguous cases about which objects are relevant for
> type-based aliasing rules.  I think it's best not to optimize this (that
> is, to treat the objects as being the individual array elements, so the
> arrays can overlap by an exact multiple of the element size - meaning the
> ultimate element size in the case of multidimensional arrays, so e.g. two
> int[4][5] arrays could be offset by one int from each other).

Ok, and I agree.

Testing the attached patch.

Richard.

2016-12-01  Richard Biener  

* tree-ssa-alias.c (indirect_refs_may_alias_p): Do not
treat arrays with same type as objects that cannot overlap.

* gcc.dg/torture/alias-2.c: New testcase.


p3
Description: Binary data

Re: Aliasing of arrays

[Joseph Myers]

On Wed, 30 Nov 2016, Richard Biener wrote:

> but that probably shouldn't apply to array types.  The idea is that
> objects of the same type cannot overlap.  Maybe Joseph can clarify whether
> and array object of known size really constitutes an object in that sense.

This is one of the ambiguous cases about which objects are relevant for 
type-based aliasing rules.  I think it's best not to optimize this (that 
is, to treat the objects as being the individual array elements, so the 
arrays can overlap by an exact multiple of the element size - meaning the 
ultimate element size in the case of multidimensional arrays, so e.g. two 
int[4][5] arrays could be offset by one int from each other).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Aliasing of arrays

[Richard Biener]

On Wed, Nov 30, 2016 at 2:19 PM, Alexander Cherepanov
 wrote:
> Hi!
>
> Pascal Cuoq communicated to me the following example:
>
> int ar1(int (*p)[3], int (*q)[3])
> {
>   (*p)[0] = 1;
>   (*q)[1] = 2;
>   return (*p)[0];
> }
>
> gcc of versions 4.9.2 and 7.0.0 20161129 optimize it with -O2 on the premise
> that elements with different indices don't alias:
>
>  :
>0:   c7 47 0c 01 00 00 00movl   $0x1,0xc(%rdi)
>7:   b8 01 00 00 00  mov$0x1,%eax
>c:   c7 46 10 02 00 00 00movl   $0x2,0x10(%rsi)
>   13:   c3  retq
>
> That's fine. But then I expect that gcc will also assume that arrays of
> different known lengths don't alias, i.e. that gcc will optimize this
> example:
>
> int ar2(int (*p)[8], int (*q)[7]) {
>   (*p)[3] = 1;
>   (*q)[3] = 2;
>   return (*p)[3];
> }
>
> But this is not optimized:
>
> 0020 :
>   20:   c7 47 0c 01 00 00 00movl   $0x1,0xc(%rdi)
>   27:   c7 46 0c 02 00 00 00movl   $0x2,0xc(%rsi)
>   2e:   8b 47 0cmov0xc(%rdi),%eax
>
> Is this behavior fully intentional, is the first example optimized too
> aggressively, is an optimization missed in the second example, or is the
> situation more complex?

I think it's a bug that we optimize ar1.  We run into

static bool
indirect_refs_may_alias_p (tree ref1 ATTRIBUTE_UNUSED, tree base1,
...
  /* 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 ((TREE_CODE (base1) != TARGET_MEM_REF
   || (!TMR_INDEX (base1) && !TMR_INDEX2 (base1)))
  && (TREE_CODE (base2) != TARGET_MEM_REF
  || (!TMR_INDEX (base2) && !TMR_INDEX2 (base2)))
  && same_type_for_tbaa (TREE_TYPE (base1), TREE_TYPE (ptrtype1)) == 1
  && same_type_for_tbaa (TREE_TYPE (base2), TREE_TYPE (ptrtype2)) == 1
  && same_type_for_tbaa (TREE_TYPE (ptrtype1),
 TREE_TYPE (ptrtype2)) == 1)
return ranges_overlap_p (offset1, max_size1, offset2, max_size2);

but that probably shouldn't apply to array types.  The idea is that
objects of the same type cannot overlap.  Maybe Joseph can clarify whether
and array object of known size really constitutes an object in that sense.

For the ar2 case the types are not equal and thus we do not use that trick
(and all array types irrespective of size get the same alias set, so
TBAA doesn't
apply here).

Richard.

>
> --
> Alexander Cherepanov

Aliasing of arrays

[Alexander Cherepanov]

Hi!

Pascal Cuoq communicated to me the following example:

int ar1(int (*p)[3], int (*q)[3])
{
  (*p)[0] = 1;
  (*q)[1] = 2;
  return (*p)[0];
}

gcc of versions 4.9.2 and 7.0.0 20161129 optimize it with -O2 on the 
premise that elements with different indices don't alias:


 :
   0:   c7 47 0c 01 00 00 00movl   $0x1,0xc(%rdi)
   7:   b8 01 00 00 00  mov$0x1,%eax
   c:   c7 46 10 02 00 00 00movl   $0x2,0x10(%rsi)
  13:   c3  retq

That's fine. But then I expect that gcc will also assume that arrays of 
different known lengths don't alias, i.e. that gcc will optimize this 
example:


int ar2(int (*p)[8], int (*q)[7]) {
  (*p)[3] = 1;
  (*q)[3] = 2;
  return (*p)[3];
}

But this is not optimized:

0020 :
  20:   c7 47 0c 01 00 00 00movl   $0x1,0xc(%rdi)
  27:   c7 46 0c 02 00 00 00movl   $0x2,0xc(%rsi)
  2e:   8b 47 0cmov0xc(%rdi),%eax

Is this behavior fully intentional, is the first example optimized too 
aggressively, is an optimization missed in the second example, or is the 
situation more complex?


--
Alexander Cherepanov