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.
