This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


> 
> 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  <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(+)
> > > >


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]