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: 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
- Date: Wed, 28 Oct 2015 00:39:49 +0100
- 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> <alpine dot LSU dot 2 dot 11 dot 1510270931100 dot 16509 at zhemvz dot fhfr dot qr>
> > 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...
My tought exactly. That three-state scheme may be useful (i.e. known
equal/known different/unknown). I think we can adjust operand_equal_p to do
that job quite easily and kill some other code duplication around .
>
> > 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).
Yep, I tried that yesterday (some limited sanity checking is already done by
gimplifier, but it misses cases). There are cases where hashing and operand_equal_p
disagree.
I suppose we can simply ignore MEM_REF and NOP_EXPR/CONVER_EXPR for hashing that
gets things more into sync.
It would be also nice to move the code to same location - with the plan to templatize
operand_equal_p we could also templatize add_expr to same place. It is needed by ipa-icf
at least.
Honza
>
> 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)