[PATCH] Make alias_sets_conflict_p less conservative

[Richard Guenther]

On Wed, 5 Mar 2008, Richard Kenner wrote:

> > So it basically asks -- is struct A in the alias set of struct B.
> 
> But that's *totally wrong* if the two access are, for example, a.x and
> b.y and (as is usually the case in C) x and y are addressable.  In
> that case, the alias sets of A and B are *completely irrelevant* and
> *all* you care about are the alias sets of x and y.  Any code that does
> something else is broken.
> 
> > > The definition of the alias set for a field x.y as used by the RTL
> > > passes has always been:
> > > 
> > > if alias_set (x) == 0 (not this case), then alias set zero
> > > else if y is addressable, then alias_set (y)
> > > else alias_set (x)
> > > 
> > > If the tree level does anything else, it is *seriously* inefficient since
> > > the entire aliasing subsetting mechanism was designed around alias sets of
> > > fields being computed in the above way.
> > 
> > but alias_set (x) _is_ zero in this case.  Because x has a char
> > member.
> 
> NO!  We DO NOT set the set to zero, but rather handle it as conflicting
> with all other alias sets.  The difference between those is *precisely*
> this algorithm.

Err, right.  But tree aliasing is computing a representation for TBAA,
using alias set conflict queries but _not_ looking at individual accesses.

So, is alias_set_subset_of () wrong as currently implemented?  Does
it lack the ase->has_zero_child test in your opinion?  Otherwise I'll
try using that for these queries.

Richard.