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: [RFC] Issues with intraprocedural devirtualization


> On 08/17/2013 05:44 PM, Jan Hubicka wrote:
> >  1) we want the type to not have base because we may have inlined the constructor.
> >     During construction the vtables are filled by base's vtable and thus we can
> >     not simply devirtualize based on the final virtual table without proving that
> >     constructor was not (partially) inlined.
> 
> If the constructor is inlined into the current function, then we can
> see the most recent assignment to the vptr and use that for
> devirtualization.

In most cases, yes.  There are some special issues, like partial inlining
(where the "wrong" assignment gets inlined, but the final assignment not) But I
think tracking inlining those (it will need to make middle end aware of
constructors that I think is good idea anyway) and leaving those to the
constant propagation should work well enough in practice.

> 
> >I do not know if one can do
> >something like having automatic variable of class A and use placement new
> >to change it to class B.
> 
> This is something of a grey area in the standard, with a few defect
> reports yet to be resolved.  I think it should be undefined
> behavior.

I would preffer it being so ;)

> 
> >Finally I decided to replace the lookup of base binfo by call to
> >get_binfo_at_offset.  This is not possible.  For example my base
> >variable can be:
> >
> >struct {class A a; class B b} var;
> >
> >and offset 10 may point to class B.  Here I get an ICE since TYPE_BINFO
> >of the structure is NULL (it is not class).
> 
> I don't understand.  In C++ a struct is a class.

You are right.  I get the ICE here only why I handle arrays and unions, too.
(as I do in my tree, but not in the patches posted). In the example above
the struct seems to have TYPE_BINFO even though it is useless.

Since handling arrays and union seems to make sense and resolves some real
testcases from firefox, I think we could keep the tree structured in a way
making this possible.  I.e. having the type walk as proposed in the patch
instead of calling get_binfo_at_offset.
> 
> >I wonder if we can track functions that return pointers/values of objects
> >    exactly of given type (i.e. no derivations).
> 
> If the function returns by value, it's always a value of that exact type.

OK, good!
> 
> >Is the dynamic type upon return from constructor always known to be of
> >    constructor's type?
> 
> Yes.
> 
> > We may want to introduce assert_type_expr use like:
> >
> >    obj_ptr = assert_type_expr<class A> obj_ptr;
> >
> >    that can be dropped by FE for us to drive those more interesting cases, like
> >    partial construction.
> 
> I guess we would need to be careful to insert those after vptr
> assignments within the constructor body, as well.

Yes, if we go this way, we will need C++ FE to produce the asserts.

The original patch seems resonable?

Honza
> 
> Jason


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