On December 24, 2015 11:15:52 AM GMT+01:00, Jan Hubicka <hubi...@ucw.cz> wrote: >> On December 23, 2015 5:58:07 PM GMT+01:00, Uros Bizjak ><ubiz...@gmail.com> wrote: >> >On Wed, Dec 23, 2015 at 2:39 PM, Richard Biener >> ><richard.guent...@gmail.com> wrote: >> >> On December 23, 2015 10:39:17 AM GMT+01:00, Uros Bizjak >> ><ubiz...@gmail.com> wrote: >> >>>Hello! >> >>> >> >>>There is a logic error in Honza's patch "Transparent alias suport >> >part >> >>>10" [1]. The part in memrefs_conflict_p should be changed to: >> >>> >> >>>- /* If decls are different or we know by offsets that there >is >> >no >> >>>overlap, >> >>>- we win. */ >> >>>- if (!cmp || !offset_overlap_p (c, xsize, ysize)) >> >>>+ /* If decls are different and we know by offsets that >> >>>+ there is no overlap, we win. */ >> >>>+ if (!cmp && !offset_overlap_p (c, xsize, ysize)) >> >>> return 0; >> >>>- /* Decls may or may not be different and offsets >overlap....*/ >> >>>+ /* Decls are different and offsets overlap....*/ >> >>> >> >>>Even if decls are different, their offsets shouldn't overlap! >> >> >> >> Comparing offsets of different decls does not make sense. >> > >> >Uh, yes, some more eyeballing was needed, but you are right. >> > >> >Is there a way to detect aliasing in case AND addresses are >involved? >> > >> >Probably we need something like in base_alias_check, where: >> >> Yeah, and in that case just give up. > >Yep, I will look into it ASAP. >comparing offsets of different decls is intended tohandle the case >where one decl is foo and other bar.
... And they resolve to the same address. For alpha we want to handle the case where an address based on decl A aliases decl B which do not resolve to the same address. That's quite different and is generally _not_ allowed in the middle-end (apart from that pesky and-addresses). We do not know of foo is not alias >of bar, but if offsets are different, we can still disambiguate >This needs to be tought over WRT anchors anyway. > >Honza >> >> Richard. >> >> >--cut here-- >> >/* The base addresses are different expressions. If they are not >> >accessed >> > via AND, there is no conflict. We can bring knowledge of >object >> > alignment into play here. For example, on alpha, "char a, b;" >can >> > alias one another, though "char a; long b;" cannot. AND addesses >may >> > implicitly alias surrounding objects; i.e. unaligned access in >DImode >> > via AND address can alias all surrounding object types except >those >> > with aligment 8 or higher. */ >> > if (GET_CODE (x) == AND && GET_CODE (y) == AND) >> > return 1; >> > if (GET_CODE (x) == AND >> > && (!CONST_INT_P (XEXP (x, 1)) >> > || (int) GET_MODE_UNIT_SIZE (y_mode) < -INTVAL (XEXP (x, 1)))) >> > return 1; >> > if (GET_CODE (y) == AND >> > && (!CONST_INT_P (XEXP (y, 1)) >> > || (int) GET_MODE_UNIT_SIZE (x_mode) < -INTVAL (XEXP (y, 1)))) >> > return 1; >> >--cut here- >> > >> >Uros. >>
