[PATCH] Make alias_sets_conflict_p less conservative

[Richard Kenner]

> 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.