[RFC] Issues with intraprocedural devirtualization

[Richard Biener]

Jason Merrill <jason@redhat.com> wrote:
>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.

I'm curious if special.casing the automatic non-pod type case is worth the trouble.  At least you need to support placement new on pod class members, in which case you need to be careful with which cases you can reliably detectat the gimple level.  As always - look at past dynamic type bugs we had with boost.

Richard.


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