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