> 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
