On Thu, 13 Jun 2019 at 14:29, Jan Hubicka <hubi...@ucw.cz> wrote:
>
> > > 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.
>
Hi!
Since this was committed (r272247), I've noticed a failure to build
glibc-2.29 for aarch64:
#'target_mem_ref' not supported by expression#'pmap_rmt.c: In function
'clnt_broadcast':
pmap_rmt.c:298:19: error: may be used uninitialized in this function
[-Werror=maybe-uninitialized]
298 | baddr.sin_addr = addrs[i];
| ~~~~~~~~~~~~~~~^~~~~~~~~~
while compiling sunrpc/pmap_rmt.os
Christophe
> Honza
