Re: [RFC] Issues with intraprocedural devirtualization

[Jason Merrill <jason at redhat dot com>]

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.

> 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.

> 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.

> 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.

> 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.

Jason