Re: Incorrect bitfield aliasing with Tree SSA

[Adam Nemet <anemet at caviumnetworks dot com>]

Richard Kenner writes:
> > 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.
> 
> OK, same question: why do you need a new alias set?  The one for the
> parent works fine.

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.

With inventing a new alias set we can hopefully *precisely* describe
the situation for the rest of the compiler.  This might give us not
just better means to argue about this issue but as far as I can see
more accurate aliasing information.

> No.  They are COMPLETELY IDENTICAL.  If you don't understand that, then
> you don't understand this issue.  This always worked right in the past.

I rather not discuss whether two are identical or not any longer.
They are not identical for practical reasons.  For bitfields making
the alias set of the field conflict with the alias set of the type of
the field is irrelevant because these types are not commonly used.  In
Ada's case this is relevant which is what Eric pointed out in his
criticism.

Adam