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

Richard Biener richard.guenther@gmail.com
Fri Jun 14 07:44:00 GMT 2019


On Thu, Jun 13, 2019 at 5:54 PM Jakub Jelinek <jakub@redhat.com> wrote:
>
> On Thu, Jun 13, 2019 at 09:50:16AM -0600, Martin Sebor wrote:
> > On 6/13/19 9:34 AM, Jakub Jelinek wrote:
> > > On Thu, Jun 13, 2019 at 09:30:37AM -0600, Martin Sebor wrote:
> > > > The size of the access above doesn't look right.  The test is:
> > >
> > > It is correct.  You have MEM <int[5]> [(int *)&i], which is
> > > the same thing as i itself, and on this you apply an ARRAY_REF,
> > > which is printed after it, with index j_1(D).  ARRAY_REF is applied on
> > > arrays and the result type is the array element type, so int in this case.
> >
> > 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.

Richard.

>         Jakub



More information about the Gcc-patches mailing list