On Thu, Jun 13, 2019 at 5:54 PM Jakub Jelinek <ja...@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
