On Mon, 17 Jun 2019, Jan Hubicka wrote:
> >
> > But part of the expensiveness we want to avoid is this
> > (repeated) walking of the ref tree...
>
> I was considering to pass contains_union_p down from one of
> earlier walks, but did not find suitable one for that...
> >
> > So...
> >
> > > + return !handled_component_p (ref2);
> > > +}
> > > +
> > > /* Return true if an indirect reference based on *PTR1 constrained
> > > to [OFFSET1, OFFSET1 + MAX_SIZE1) may alias a variable based on BASE2
> > > constrained to [OFFSET2, OFFSET2 + MAX_SIZE2). *PTR1 and BASE2 have
> > > @@ -1533,7 +1563,12 @@ indirect_ref_may_alias_decl_p (tree ref1
> > > && (TREE_CODE (TREE_TYPE (base1)) != ARRAY_TYPE
> > > || (TYPE_SIZE (TREE_TYPE (base1))
> > > && TREE_CODE (TYPE_SIZE (TREE_TYPE (base1))) == INTEGER_CST)))
> > > - return ranges_maybe_overlap_p (doffset1, max_size1, doffset2,
> > > max_size2);
> > > + {
> > > + if (!ranges_maybe_overlap_p (doffset1, max_size1, doffset2,
> > > max_size2))
> > > + return false;
> > > + if (same_access_paths_p (ref1, max_size1, ref2, max_size2))
> > > + return true;
> >
> > how about a simpler test like
> >
> > if (known_size_p (max_size1) && known_size_p (max_size2))
> > return true;
> > /* If there's an unconstrained variable access in the ref fall
> > through to access-path based disambiguation. */
>
> If I have something like
> struct a {int a[10];int b;}
> and then
> aptr->a[i]
> in the access path, won't be max_size known (40) where type size is 4?
Yes.
> In this case I want to contiue to access path.
> >
> > ?
> >
> > I'd certainly like to see testcases btw...
>
> There is a testcase for variable array access included in the patch,
> would you like to have one with union in it?
Oh, I missed the testcase ;)
> >
> > A more stricter test would be
> >
> > if (!maybe_eq (max_size1, size1) && !maybe_eq (max_size2, size2))
> > return true;
> > /* If there's a variable access in one of the refs fall through
> > to access-path based disambiguation. */
> >
> > where you'd need to pass down ao_ref_size in addition to max_size as well.
>
> Proably || here?
Hmm, !maybe_eq () -> ! max_size1 == size1 -> max_size != size1 thus
I think && is correct if you want to disambiguate a[1].v2 and a[i].v1
But yes, if you don't want that then || is cheaper. Probably add
another testcase with one of the accesses with a constant index?
Richard.
