This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Bug fix: *var and MEM[(const int *)var] (var has int* type) are not treated as the same data ref.


On Mon, Sep 23, 2013 at 05:26:13PM -0700, Cong Hou wrote:

Missing ChangeLog entry.

> --- gcc/testsuite/gcc.dg/alias-14.c (revision 0)
> +++ gcc/testsuite/gcc.dg/alias-14.c (revision 0)

Vectorizer tests should go into gcc.dg/vect/ instead, or, if they are
for a single target (but there is no reason why this should be a single
target), into<target>/.

> --- gcc/fold-const.c (revision 202662)
> +++ gcc/fold-const.c (working copy)
> @@ -2693,8 +2693,9 @@ operand_equal_p (const_tree arg0, const_
>         && operand_equal_p (TYPE_SIZE (TREE_TYPE (arg0)),
>     TYPE_SIZE (TREE_TYPE (arg1)), flags)))
>    && types_compatible_p (TREE_TYPE (arg0), TREE_TYPE (arg1))
> +  && types_compatible_p (
>    && OP_SAME (0) && OP_SAME (1));

This looks wrong.  types_compatible_p will happily return true say
for unsigned long and unsigned long long types on x86_64, because
they are both integral types with the same precision, but the second
argument of MEM_REF contains aliasing information, where the distinction
between the two is important.
So, while == comparison of main variant is too strict, types_compatible_p
is too weak, so I guess you need to write a new predicate that will either
handle the == and a few special cases that are safe to be handled, or
look for what exactly we use the type of the second MEM_REF argument
and check those properties.  We certainly need that
get_deref_alias_set_1 and get_deref_alias_set return the same values
for both the types, but whether that is the only information we are using,
not sure, CCing Richard.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]