> > > 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
