This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 3/9] operand_equal_p: add support for OBJ_TYPE_REF.
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(+)
> > > > >