On Fri, Aug 16, 2019 at 2:07 PM Jan Hubicka <hubi...@ucw.cz> wrote: > > > > > 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.
But we also compare OBJ_TYPE_REF_EXPR and later we expand to a call with exactly that address... > > > > 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(+) > > > > >
