Re: Incorrect bitfield aliasing with Tree SSA

[kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)]

> No.  Types have alias sets. That's why it's type based aliasing.
> Field has a type, and thus, the field should have an alias. set
> That's why using DECL_NONADDRESSABLE_P is so wrong.  It has nothing to
> do with the subset relationship of the types, 

Of course not!  That's the whole point: the "subset relationship"
is completely irrelevant because you can't access the field in its native
type.  If you persist in wanting to think of the field itself as having
an alias set (instead of just thinking of a reference as having an alias set),
then the proper way to think about it is that the alias set of such a
field is that of the type of the record it's in.

> component_uses_parent_alias_set is a hack around the fact that you
> want a pointer to the first field of the structure to alias the field,
> and you want stores to the entire structure to alias the field, but
> you want nothing else to alias the field.

Huh?  Why does it matter if the field in question is the first field,
second field, or whatever?

> 1. Record the type as a subset of the structure, as the types actually
> say is the relationship, and use DECL_NON_ADDRESSABLE_P on a
> per-access basis

No.  That's COMPLETELY wrong.  NOTHING should be done with the type of 
the field.

Let's look at the C case.  Suppose I have:

	struct r1 {int xyz:1;};
	struct r2 {short abc:1;};

	int *p1;
	short *p2;

The fact that R1 is "int" and R2 is "short" shows the point that the type of
the field is completely irrelevant and shouldn't be used for anything.  A
store through p1 OR p2 doesn't affect any object of struct r1 or struct r2.
Every reference to objects of type "struct r1" should have that alias set and
every reference to objects of type "struct r2" should have that alias set and
"int" and "short" should be COMPLETELY uninvolved.

> What we have now, where we try to use the alias set of the parent
> component, is not right and generates wrong answers, as you've seen.

No, I haven't seen this. The RTL dumps look correct.  get_alias_set
looks correct.  No other code should try to compute alias sets of
expressions.  If there is some other such code, it's a bug and should
be fixed.