This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Use OEP_ADDRESS_OF in emit-rtl.c
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Richard Biener <rguenther at suse dot de>
- Cc: Jan Hubicka <hubicka at ucw dot cz>, gcc-patches at gcc dot gnu dot org, law at redhat dot com
- Date: Thu, 8 Oct 2015 18:14:02 +0200
- Subject: Re: Use OEP_ADDRESS_OF in emit-rtl.c
- Authentication-results: sourceware.org; auth=none
- References: <20151007052926 dot GA5527 at kam dot mff dot cuni dot cz> <alpine dot LSU dot 2 dot 11 dot 1510071027440 dot 6516 at zhemvz dot fhfr dot qr> <20151007173340 dot GB65469 at kam dot mff dot cuni dot cz> <alpine dot LSU dot 2 dot 11 dot 1510080932050 dot 6516 at zhemvz dot fhfr dot qr>
> 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 that doesn't break dependences.
> >
> > Hmm, expr is used by ao_ref_from_mem and nonoverlapping_memrefs_p.
> > The alias set of the access is not taken from expr, but from alias set info
> > stored in the memory attribute itself (and it is checked by those to match)
>
> But the alias-set is not everything and yes, via ao_ref_from_mem MEM_EXPR
> "leaks" to the tree oracle which happily calls
> nonoverlapping_component_refs_of_decl_p or nonoverlapping_component_refs_p
> on it.
>
> > I still think it is an address of the expression that matters, not the value.
> > I think operand_equal_p may, for example, consider two different VAR_DECL equivalent
> > if their constructors are, because the value is (it doesn't do that), but their
> > addresses differ.
>
> It's structural equality of the MEM_EXPR that matters. That neither
> operand_equal_p (..., 0) nor operand_equal_p (..., OEP_ADDRESS_OF) is
> an exact implementation for this (well, I think with '0' flags it was
> designed to be this, at least for memory references) is of course
> suspicious. But that doesn't make using OEP_ADDRESS_OF the correct thing
> to do.
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 would basically expect decls and mem_refs here. Reason why I started to look
into that is that I added sanity check that operand_equal_p (...,0) is not called
on things that do not have value (function types and incomplete types) and this
is one of places that fires.
>
> > I will look more into nonoverlapping_memrefs_p and ao_ref_from_mem. The first
> > one may need some update to tree-alias infrastructure....
>
> I'd rather remove it completely (at least that was my plan eventually).
> rtx_refs_may_alias_p is supposed to handle everything it handles.
Yep, that was my feeling from looking into that yesterday....
Honza