Richard Biener <rguent...@suse.de> writes:
> 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?
Might be misunderstanding, but isn't the check for a variable access
!known_eq (max_size1, size1) == maybe_ne (max_size1, size1)? "maybe_eq"
means "could be equal in some circumstances, even if they're not always
equal".
Richard
