On Wed, 7 Oct 2015, Jan Hubicka wrote:

> Hi,
> adding some extra sanity checks to operand_equal_p made me to notice that uses
> of operand_equal_p in mem attrs really care about addresses only.  The 
> expression
> is tree of the original memory acces MEM RTX was created from and thus the
> comparsions should be done with OEP_ADDRESS_OF.
> 
> Bootstrapped/regtested x86_64-linux, OK?

Did you audit all callers of mem_attrs_eq_p to see if they really
only care about that?  After all MEM_EXPR, via access paths, encode
type-based alias info and thus replacing one with the other (cse.c use
or ifcvt.c use) is only valid if that doesn't break dependences.

So I don't believe this is safe.

Thanks,
Richard.

> Honza
> 
>       * emit-rtl.c (mem_attrs_eq_p, mem_expr_equal_p): Pass OEP_ADDRESS_OF
>       to operand_equal_p.
> 
> Index: emit-rtl.c
> ===================================================================
> --- emit-rtl.c        (revision 228131)
> +++ emit-rtl.c        (working copy)
> @@ -334,7 +334,7 @@ mem_attrs_eq_p (const struct mem_attrs *
>         && p->addrspace == q->addrspace
>         && (p->expr == q->expr
>             || (p->expr != NULL_TREE && q->expr != NULL_TREE
> -               && operand_equal_p (p->expr, q->expr, 0))));
> +               && operand_equal_p (p->expr, q->expr, OEP_ADDRESS_OF))));
>  }
>  
>  /* Set MEM's memory attributes so that they are the same as ATTRS.  */
> @@ -1657,7 +1657,7 @@ mem_expr_equal_p (const_tree expr1, cons
>    if (TREE_CODE (expr1) != TREE_CODE (expr2))
>      return 0;
>  
> -  return operand_equal_p (expr1, expr2, 0);
> +  return operand_equal_p (expr1, expr2, OEP_ADDRESS_OF);
>  }
>  
>  /* Return OFFSET if XEXP (MEM, 0) - OFFSET is known to be ALIGN
> 
> 

-- 
Richard Biener <rguent...@suse.de>
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 
21284 (AG Nuernberg)

Reply via email to