Re: Incorrect bitfield aliasing with Tree SSA

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

> Yes it works (or worked more precisely) but it does not fully describe
> the situation, it rather works around it.  It equates two aliases that
> are really not.  One is what the structure can alias and the other
> what a field can.  The two are obviously not the same but I agree if
> you make them the same, things more or less work.  The problem is that
> it is not the complete reality.

I disagree.  If we have, say, an 8-byte integer and we give an alias set to
that type, let's say 123, that's the alias set that is to be used to access
any and all parts of the integer that can't be pointed to be a pointer of
some other type.  So if you have a single-byte access into the integer, it's
alias set 123.  That seems perfectly natural and I don't think anybody would
suggest making a new alias set for accessing pieces of the integer.

Now consider 

	struct foo {int a:32; int b:32; };

(I use the bitfield reference to show the same that omitting "aliased" in
Ada will me: no int * expression can point to it.)

This is also an 8-byte object.  Let's say the alias set for that is 234.  If
I access the entire struct, we use alias set 234.  Just like the integer
case, no subpart of that 8-byte object can be pointed to by anything other
than a pointer to that type.  So why should there be any difference from the
integer case if I access just one byte of that, say the low-order byte of
field "a"?  That should also be alias set 234.  After all, if, for some
reason, we implemented a block move with single-byte moves, those would ALSO
be alias set 234.

Why should any other alias set be involved in any of these accesses?  That's
what seems unnatural to me.