> > Hmm, I see. I wonder how complex the expressions are and if we can't simply
> > compare AO properties of MEM_REF at toplevel and then dispatch to
> > operand_equal_p (..., OEP_ADDRESS_OF)
> > which would make more sense to me.
>
> I can't see how we can do that comparison conservatively witho
On Thu, 8 Oct 2015, Jan Hubicka wrote:
> > On Wed, 7 Oct 2015, Jan Hubicka wrote:
> >
> > > >
> > > > 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
> On Wed, 7 Oct 2015, Jan Hubicka wrote:
>
> > >
> > > 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
On Wed, 7 Oct 2015, Jan Hubicka wrote:
> >
> > 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
>
> 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.
Hmm, expr is used
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
> compar
