On 6/18/07, Richard Kenner <[EMAIL PROTECTED]> wrote:
> 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.
Where I'm lost here is why you need do anything whatsoever! If you ask
for the alias set of something, get_alias_set *already* does the right
thing.
It does not do the above, so it does not do the correct thing.
It gives you the alias set of the parent, which, for the reason that
OTHER THINGS USE THE ALIAS SET SPLAY TREES, gives the wrong answer.
This is not, and has never been about get_alias set.
There are other queries to the splay trees that is generated from
get_alias_set than alias_sets_conflict_p
All you have to do is look at the splay tree lookups in alias.c, and
you will see alias_subset_of
Or is the issue that you're calling get_alias_set on a FIELD_DECL
I'm not sure what a "TBAA forest" is, but keep in mind that, at least in
Ada, we have many different types (meaning different tree nodes) that have
the same alias set and we really do mean that they are to conflict.
That's nice.
This is why it's a concern to me if we're not uniformly using the same
functions at the tree and RTL level to compute alias sets.
Sigh, I give up.
We are computing the alias sets only using get_alias_set
There are other questions we ask about alias sets other than "do these
two alias sets conflict" (which is asking whether they are subsets of
each other, or equal). We have good reasons to ask these questions.
By creating TBAA info that makes fields not subsets of their parents
you don't break alias_sets_conflict_p (which is all RTL ever uses),
but you break *all the other questions we ask about relationships
between alias sets*, which is what the tree level uses.
