Re: Incorrect bitfield aliasing with Tree SSA

[Adam Nemet <anemet at caviumnetworks dot com>]

Richard Kenner writes:
> > Wouldn't this be as simple as assigning the type of
> > DECL_NONADDRESSABLE_P fields to a different alias set than the alias
> > set of the type.
> 
> No.  You assign those fields precisely to the alias set of the type of
> the record that it's in.  Why would you want to make a new type?

Not a new type just a new alias set.  As you return the parent alias
set of the field right now you might as well return a separate alias
set different from the type's alias set.

So far I learned about two requirements:

  1) We need to correctly track the subset relationship so that
  structure-field aliasing receives valid information.  Without this
  we miss the reference to the field when the parent is accessed.

  2) We should do the above without introducing a new conflict between
  the alias set of the field's type and the alias set of the parent
  type.

Basically what I am working on is to optionally have another alias set
for each type which is not directly addressable.  This new alias set
would only conflict with the alias set of its parent (1).  At the same
time we can make it not conflict with the addressable/original alias
set of the same type.  This is 2 above.

> For one thing, the C bitfield cases and the Ada non-aliased cases
> are *identical*: in both cases, a pointer to the type of the field
> can't conflict with a reference to the type of the struct.

Right but the two cases are different in the complexity of the
solution they require.  For bitfields we can just record the subtype
relationship whereas for Ada the subtyping would introduce unnecessary
dependecies.

Adam