This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Drop types_compatible_p from operand_equal_p
- From: Richard Biener <rguenther at suse dot de>
- To: Jan Hubicka <hubicka at ucw dot cz>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Tue, 27 Oct 2015 09:33:16 +0100 (CET)
- Subject: Re: Drop types_compatible_p from operand_equal_p
- Authentication-results: sourceware.org; auth=none
- References: <20151023234111 dot GB83055 at kam dot mff dot cuni dot cz> <alpine dot LSU dot 2 dot 11 dot 1510260930120 dot 16509 at zhemvz dot fhfr dot qr> <20151026170430 dot GA16335 at kam dot mff dot cuni dot cz>
On Mon, 26 Oct 2015, Jan Hubicka wrote:
> > On Sat, 24 Oct 2015, Jan Hubicka wrote:
> >
> > > Hi, as discussed earlier, the types_compatible_p in operand_equal_p
> > > seems redundant. (it is callers work to figure out how much of type
> > > matching it wants. If not, we probably want to treat most of other
> > > references and casts simlar way).
> > >
> > > Bootstrapped/regtested x86_64-linux. OK?
> >
> > Ok.
> >
> > Btw, you need to audit tree hashing for required changes with respect
> > to your ones to operand_equal_p. operand_equal_p is the equality
> > function for it.
>
> Yep, I am aware that tree hasing must match. I think my changes are safe so
> far:
> - ctors are already hashed resonably
> - types are not hashed so the changes strenghtening OEP_ADDRESS_OF are safe
> - OEP_ADDRESS_OF (so far) still boils down to syntactic matching.
>
> Looking at this I noticed that simple_cst_equal in tree.c seems to reimplement
> OEP_CONSTANT part of operand_equal_p and it seems to have bugs - i.e. not
> comparing index for CONSTRUCTOR ELTs.
simple_cst_equal is also quite incomplete and I'd rather have it die...
> Also I was always bit unsure how the path through operand_equal_p that allows
> different tree codes to match (stripping MEM_REF) and use of STRIP_NOPS combine
> with add_expr that doesn't do these. Do we have some mechanism that will
> prevent this from corrupting hashtables?
We should ensure that equal trees get equal hash codes (heh, probably
easy to add a wrapper around operand_equal_p double-checking that).
Richard.
> Honza
> >
> > Thanks,
> > Richard.
> >
> > > * fold-const.c (operand_equal_p): Drop types_compatible_p when
> > > comparing references.
> > >
> > > Index: fold-const.c
> > > ===================================================================
> > > --- fold-const.c (revision 229278)
> > > +++ fold-const.c (working copy)
> > > @@ -2982,9 +2982,6 @@ operand_equal_p (const_tree arg0, const_
> > > TYPE_SIZE (TREE_TYPE (arg1)),
> > > flags)))
> > > return 0;
> > > - /* Verify that access happens in similar types. */
> > > - if (!types_compatible_p (TREE_TYPE (arg0), TREE_TYPE (arg1)))
> > > - return 0;
> > > /* Verify that accesses are TBAA compatible. */
> > > if (flag_strict_aliasing
> > > && (!alias_ptr_types_compatible_p
> > >
> > >
> >
> > --
> > Richard Biener <rguenther@suse.de>
> > SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)
>
>
--
Richard Biener <rguenther@suse.de>
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)