> > 1) indirect_refs_may_alias_decl_p passing ref2_is_decl as true to
> > aliasing_component_refs_p.
> >
> > This makes aliasing_component_refs_p to assume that all access paths
> > conflicting with REF2 must start by type of BASE2 or its subtype.
> >
> > IMO this is not quite right in gimple memory model where decls are just
> > untyped memory slots, since I can, for example, I can rewrite decl
> > of type a by a new data of type struct b {struct a a;};
> > which will confuse this logic.
>
> The above check you complain about guards against this.
Not sufficinly. ref1 can be store of type "struct b". With ref2 of
base type "struct a" (which is in conflict) the oracle will currently
disambiguate because it will not consider the path
"struct b"..."struct a" due to that ref2_is_decl check.
> > Sincce we already checked that TREEE_TYPE (ptrtype) is same as
> > TREE_TYPE (base1)
> > the same_type_for_tbaa check is equivalent in both.
> >
> > Notice however that first tests that array is VLA, while other
> > supports partial overlaps on all array types. I suppose we want to
> > choose which way we support that and go with one or another.
>
> Let's go with the stricter check for the purpose of unification and work
> on this issue as followup.
Yep, that is my plan. W/o that this that alias-2.c array overlap
testcase would break (and it breaks if one of accesses is through decl).
Concerning the unification, I am still confinced we want to test
base2_alias_set to be non-zero in indirect_ref_may_alias_decl_p
(same way as we do in indirect_refs_may_alias_p) as discussed in thread
https://gcc.gnu.org/ml/gcc-patches/2019-06/msg00087.html
Because we can not assume that there are no dynamic type changes on
decls in gimple memory model.
I also need to dig into the divergence between
nonoverlapping_component_refs_of_decl_p and
nonoverlapping_component_refs_p. It seems to me that having the decl in
hand does not buy us much here either.
Notice that one tries to match structures only, while other handles
unions too. For LTO as well for code merging even w/o LTO it would be
nice to keep alias between
union {int a; int b;};
and ptr->a an ptr->b (which we currently do), but it seems it is
guaranteed only by the second function.
Honza
