Incorrect bitfield aliasing with Tree SSA

[Daniel Berlin]

On 6/15/07, Adam Nemet <anemet@caviumnetworks.com> wrote:
> Daniel Berlin writes:
> > On 6/15/07, Adam Nemet <anemet@caviumnetworks.com> wrote:
> > > get_alias_set and internally record_component_aliases makes
> > > assumptions about the IR that are only valid in RTL.
> >
> > What is this assumption, exactly?
>
> That non-addressable fields are always accessed through alias set 0.
> For example:
>
>   X: (set (mem A) ...)
>   Y: (set (zero_extract (mem B) 2 2) ...)
>
> Let's say that A and B both point to the same type and have the same
> alias set 1.  The bitfield store in Y would normally have the alias
> set of the field, let's say 2.  Normally 2 would have to be recorded
> as an alias subset of 1.  This is not done in RTL and the comment
> before record_component_aliases mentions this:
>
> /* Record that component types of TYPE, if any, are part of that type for
>    aliasing purposes.  For record types, we only record component types
>    for fields that are marked addressable.

HMm, i'd just record it for all of them, since the are accessible
through a pointer to the structure.
Just because you can't directly take the address of a bitfield doesn't
mean you can't access one through a pointer, which is the entire
purpose of knowing alias sets (knowing what a pointer dereference
could affect).

This should solve the problem without having to do anything IR specific.