[PATCH 3/9] operand_equal_p: add support for OBJ_TYPE_REF.

[Jan Hubicka]

> On Tue, Aug 6, 2019 at 5:43 PM Martin Liska <mliska@suse.cz> wrote:
> >
> >
> > gcc/ChangeLog:
> 
> +       /* Virtual table call.  */
> +       case OBJ_TYPE_REF:
> +         {
> +           if (!operand_equal_p (OBJ_TYPE_REF_EXPR (arg0),
> +                                 OBJ_TYPE_REF_EXPR (arg1), flags))
> +             return false;
> +           if (virtual_method_call_p (arg0))
> +             {
> +               if (tree_to_uhwi (OBJ_TYPE_REF_TOKEN (arg0))
> +                   != tree_to_uhwi (OBJ_TYPE_REF_TOKEN (arg1)))
> +                 return false;
> +               if (!types_same_for_odr (obj_type_ref_class (arg0),
> +                                        obj_type_ref_class (arg1)))
> +                 return false;
> +               if (!operand_equal_p (OBJ_TYPE_REF_OBJECT (arg0),
> +                                     OBJ_TYPE_REF_OBJECT (arg1), flags))
> +                 return false;
> 
> this all gets deep into the devirt machinery, including looking at
> ODR type hashes.  So I'm not sure if we really want to handle
> it this "optimistic" in operand_equal_p and completely ignore
> other operands when !virtual_method_call_p?  That is, why
> not compare OBJ_TYPE_REF_TOKEN/OBJECT always at least?

For !virtual_method_call_p we do not use OBJ_TYPE_REF at all yet obj-C frontend
produce it.  I think we should remove them somewhere during gimplification.
We can definitly turn "optimistic" to "pesimistic" and return false here.

Otherwise the checks makes sense to me - it the tests above passes devirt
machinery ought to give same results.
> 
> Do we then have cases where the OBJ_TYPE_REF is actually
> distinct according to the remaining check?

I am not sure what you mean here?

Honza
> 
> +             }
> 
> 
> > 2019-07-24  Martin Liska  <mliska@suse.cz>
> >
> >         * fold-const.c (operand_equal_p): Support OBJ_TYPE_REF.
> >         * tree.c (add_expr): Hash parts of OBJ_TYPE_REF.
> > ---
> >  gcc/fold-const.c | 21 +++++++++++++++++++++
> >  gcc/tree.c       |  9 +++++++++
> >  2 files changed, 30 insertions(+)
> >