Incorrect bitfield aliasing with Tree SSA

[Daniel Berlin]

On 6/18/07, Richard Kenner <kenner@vlsi1.ultra.nyu.edu> wrote:
> > > But throws away the entire DECL_NONADDRESSABLE_P mechanism!
> >
> > No, an int* will still not conflict with int:31
> > a short * will still not conflict with short:31
>
> Using what mechanism?  That's what DECL_NONADDRESSABLE_P does!

Please read what the *second* proposal was again

1. The alias set is a subset of the parent set
and more importantly
2. The alias set is different than that of the underlying type and the
parent set.

Thus, the alias sets will not conflict with the underlying type, but
will conflict with the parent set which is exactly what you want.

How does this get a different result for trees than RTL?

As i've explained, we rely on the proper of the TBAA forest that given

  struct foo (set 1)
  /                                 \
int :31  (set 2)  short :31 (set 3)

sets for int :31 and short :31 are strict subsets of that of struct
foo.  This is how it is documented and except for this one little wart
introduced by DECL_NONADDRESSABLE_P, how it is.

For the sake of a complete example, we also have int (set 4) and short
(set 5), which are both roots of this forest, and thus, do not
conflict with set 3 or 2.

The forest we have now says:

struct foo, int :31, short :31   (set 1)

(and int = set 4 and short = set 5).
Note again that in neither forest  does set 1 conflict with 4 or 5,
but in the first forest, the subset relationship between int:31 and
struct foo is properly represented as subset but different.

As I said to Eric, you can also change the strict subset to
subset_or_equals, but that is really not quite in accord with reality.
 They *really are different alias sets than their parent*.

Note also that it is more precise in the first case.
If you were ever to ask "can int:31 touch short:31", the first forest
would correctly say no, what we have now would say "yes".

>
> > Tell me what TYPE_NONALIASED_COMPONENT does, and i'll tell you what
> > will happen right now :)
>
> Very similar.  If I have
>
>         typedef xyz[100] foo;
>
> and mark that type with that flag, it means that int * will not conflict
> with it, just foo *.


Then these should simply have different non-conflicting aliasing sets :)