Jan Hubicka <hubi...@ucw.cz> 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 >> >> > to access-path based disambiguation. */ >> >> > >> >> > where you'd need to pass down ao_ref_size in addition to max_size as >> >> > well. >> >> >> >> Proably || here? >> > >> > 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? >> >> Might be misunderstanding, but isn't the check for a variable access >> !known_eq (max_size1, size1) == maybe_ne (max_size1, size1)? "maybe_eq" >> means "could be equal in some circumstances, even if they're not always >> equal". > > Seems I am getting progressively more confused.
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. But I was just picking up on the choice of maybe_eq vs. known_eq in the condition, which as things stand would only matter for SVE. And... > I think I want to pass the size down from ao_ref to the functions and > then see if they are always equal. ...right, that's what I mean. known_eq gives you "always equal", i.e. "not variable". The maybe_eq in the original condition seemed odd because it includes the constant case and (potentially) variable cases that are size1 or bigger. In inverted conditions, !known_eq can be written maybe_ne (but doesn't need to be, if !known_eq seems clearer). Thanks, Richard > > Why would I want to use maybe variant? > > Honza > >> >> Richard
