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)