> >Well, me too :-) I didn't really understand the choice of the original
> >condition above. It seemed to be "return true if both access sizes are
> >variable", but the comment implied something else.
>
> Sorry,! Must_eq is obviously fine.
Thanks, good to know we are on same page :)
After som
On June 17, 2019 6:23:03 PM GMT+02:00, Richard Sandiford
wrote:
>Jan Hubicka writes:
>>> >> >
>>> >> > A more stricter test would be
>>> >> >
>>> >> >if (!maybe_eq (max_size1, size1) && !maybe_eq (max_size2,
>size2))
>>> >> > return true;
>>> >> > /* If there's a vari
Jan Hubicka writes:
>> >> >
>> >> > 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
>> >> >t
> >> >
> >> > 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. */
> >>
Richard Biener 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 tha
> On Mon, 17 Jun 2019, Jan Hubicka wrote:
>
> > >
> > > 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 test
On Mon, 17 Jun 2019, Jan Hubicka wrote:
> >
> > 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
>
> 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?
Hmm, OK, withou
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...
> >
> > > +
Hi,
this is testcase for unions. It is somewhat artificial because
nonoverlapping_component_refs is conservative about matching union
fields and aliasing_component_refs_p resorts to offset/max_size
test which of course suceeds.
So I had to add the wrapping struct a (which is matched by
the earlier
>
> 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);
> > +}
> > +
> > /* Ret
On Mon, 17 Jun 2019, Jan Hubicka wrote:
> Hi,
> while working on testcases for nonoverlapping_component_refs_p I run into
> issue
> that we often bypass it because the indirect-decl and indirect-indirect
> oracles
> give up if they manage to match bases and ranges_maybe_overlap_p return true.
>
12 matches
Mail list logo
