> On Tue, Aug 6, 2019 at 5:43 PM Martin Liska <mli...@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 <mli...@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(+) > >