Re: Type-based alias analysis and alias sets

[Richard Guenther <rguenther at suse dot de>]

On Fri, 23 Oct 2009, Eric Botcazou wrote:

> > I didn't find (or could construct) a single C or C++ testcase that
> > wasn't fine with the new default, so I switched it (IIRC the default
> > is disambiguating the most cases).
> 
> Yes, the default is the optimistic answer and a few tests rely on it:
> 
> FAIL: gcc.dg/tree-ssa/alias-18.c scan-tree-dump fre "with 1"
> FAIL: gcc.dg/tree-ssa/pr13146.c scan-tree-dump optimized "return 0;"
> FAIL: gcc.dg/tree-ssa/pr27799.c (test for excess errors)
> FAIL: gcc.dg/tree-ssa/pr38895.c scan-tree-dump optimized "return 1;"

Indeed, I added them for this reason.

> For alias-18.c:
> 
> struct A {
>   int i;
>   int j;
>   float x;
> };
> struct B {
>   struct A a;
>   int k;
> };
> 
> int test1 (struct A *p, struct B *q)
> {
>   p->i = 1;
>   q->k = -1;
>   return p->i;
> }
> 
> the 1 is expected to be propagated but isn't if the default is changed.
> 
> IIUC the key here is that 'struct A' is a sub-structure of 'struct B' so, if 
> *p is not in the access path of *q, the references cannot alias.  So I can 
> propose this for the end of nonaliasing_component_refs_p:

btw, aliasing_component_refs_p would be a fine name.

>   /* We haven't found any common base to apply offset-based disambiguation.
>      There are two cases:
>        1. The base access types have the same alias set.  This can happen
> 	  in Ada when a function with an unconstrained parameter passed by
> 	  reference is called on a constrained object and inlined: the types
> 	  have the same alias set but aren't equivalent.  The references may
> 	  alias in this case.
>        2. The base access types don't have the same alias set, i.e. one set
> 	  is a subset of the other.  We have proved that B1 is not in the
> 	  access path B2.path and that B2 is not in the access path B1.path
> 	  so the references may not alias.  */
>   return get_alias_set (type1) == get_alias_set (type2);

That works for me.  A patch along this line is pre-approved.

Thanks,
Richard.