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

[Richard Biener <richard.guenther@gmail.com>]

On Fri, Aug 16, 2019 at 2:07 PM Jan Hubicka <hubicka@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  <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(+)
> > > > >