> > When we compare OBJ_TYPE_REF_TOKEN and OBJ_TYPE_REF_OBJECT > and they are equal, are there cases where types_same_for_odr returns false?
OBJ_TYPE_REF_OBJECT is pointer to the instance, OBJ_TYPE_REF_TOKEN is index in the vtable or the type given by obj_ref_type_class. I guess one can do something like void *ptr; ... if (cond) ((class_a *)ptr)->firstvirtualmethod_of_class_a (); else ((class_b *)ptr)->firstvirtualmethod_of_class_b (); Here OBJECT will be always *ptr, TOKEN will be 0, but the actual virtual method is different. So merging this may lead to invalid devirtualization at least when the classes are anonymous namespace and we work out late in compilation that they are not derived. > > I guess we went over this some time ago when talking about value-numbering > of them. I realize the devirt machinery use the class type to get at the > virtual table but since we later expand simply OBJ_TPE_REF_EXPR _that_ > already has the result of the load from the vitual table. > > So - do we need to compare obj_type_ref_class at all? The worst thing > that could happen is that devirt no longer can devirtualize after the merging > but it should never result in "wrong" devirtualization? So, do we really > want to inhibit ICF of two equal functions that could be eventually > devirtualized both but into different direct calls? Can't this sort of thing I think it is like with the TBAA info. I would suggest first implement tests that preserve correctness of both TBAA and devirt annotations. Incrementally we can teach ICF to be agressive with -Os and merge anyway while dropping the metadata (removing OBJ_TYPE_REF or adjusting alias sets > happen anyway when you'd factor in IPA-CP and two identical functions > with indirect calls to a function argument but called with different constant > args? And should IPA-CP then not consider cloning after ICF merging > (not sure how ordering works here). I am not sure how those are realated. For sure IPA-CP can clone when it works out that different types are passed to the function and devirtualize to different calls. But this is bit different - it is about the type annotation we Honza > > Richard. > > > 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(+) > > > >
