[PATCH] include MEM_REF type in tree dumps (PR 90676)

Jan Hubicka hubicka@ucw.cz
Fri Jun 14 08:51:00 GMT 2019


> > > Aah, it's two REFs in one.  I misread the array index as being
> > > a part of the MEM_REF operand, like this:
> > >
> > >   MEM <int[5]> [((int *)&i)[j_1(D)]] = 1;
> > >
> > > I guess I've never noticed this before.  Why is the whole thing
> > > not simplified to an ARRAY_REF?
> > >
> > >   i[j_2(D)] = 1;
> >
> > No idea in this case, though of course there can be other cases e.g.
> > where the MEM_REF has different number of elements, different element type
> > etc. from the underlying variable or where the MEM_REF first operand is not
> > address, but pointer.
> 
> We elide the MEM_REF only if the TBAA type exactly matches the value-type.
> Since TBAA-wise an array is the same as the element type (unless the
> language says otherwise - see get_alias_set) we could in some cases with
> arrays elide it.  It didn't seem worth the extra complexity in the code doing
> this, see maybe_canonicalize_mem_ref_addr.  Honza is at the moment
> trying to improve access-path disambiguation which runs into related issues.

I have just sent an email with some analysis running into it on vect
testcase.  I think we ought to solve this - it seems to be relatively
common case and my proposed patch makes it worse (and I think for valid
reasons)

Honza
> 
> Richard.
> 
> >         Jakub



More information about the Gcc-patches mailing list