[PATCH, PR 45934] Devirtualization aware of dynamic type changes

[Gabriel Dos Reis]

On Tue, Nov 23, 2010 at 5:42 PM, Jay K <jay.krell@cornell.edu> wrote:
> ----------------------------------------
>> Date: Tue, 23 Nov 2010 17:22:59 -0600
>> Subject: Re: [PATCH, PR 45934] Devirtualization aware of dynamic type changes
>> From: gdr@integrable-solutions.net
>> To: jay.krell@cornell.edu
>> CC: gcc-patches@gcc.gnu.org; hubicka@ucw.cz; rguenther@suse.de; mjambor@suse.cz
>>
>> On Tue, Nov 23, 2010 at 4:48 PM, Jay K wrote:
>> >
>> > Hm. Since the vtable pointer can change at almost any point,
>  [...]
>>
>> the vtable chaning happens during construction and destruction of
>> an object. It is not random.
>>
> [ ... ]
>>
>> Please note that the issue isnt a language like C++ being unsafe.
>> In fact, the C++ semantics for inheritance and virtual function dispatch
>> is provably sound.
>>
>> I believe the middle end has to be conservative about devirtualization.
>> During an object lifetime, the dynamic type does not change
>> (therefore the vtable does not.)
>> Before an object's lifetime starts and after it ends (but before the destructor
>> finishes) there are only very limited operations that can be done
>> counting on virtual function dispatch. The rules have been crafted so that
>> a "stack" discipline of vtable changes is obeyed. The tricky part
>> is to ensure that one gets the "right" value of "this" at each point (end
>> therefore the right value the vtable.)
>
>
>
> I understand that the vtable goes from base to more derived as the base to more derived constructors run.

It is slightly more complicated than that if you have multiple
inheritance, but yes it
is essentially from base to derived.

>  (in C++, not Java)
> However, is the compiler not obligated to let me pound on random memory through casting, memcpy, etc.?

Nop.  As I said, the set of valid operations that can be performed before
the constructor finishes and before the object's lifetime begins is quite
restricted.  If you like fiddling with bytes and casting, be prepared to
be on your own.

> Including copying vtable pointers from one object/type to another?
> Or perhaps it isn't?

The C++ language does not talk about vtable, so what exactly what operations
do you refer to by `copying vtable pointers'?

>
>
> If not, the problem is merely for the middle-end to recognize whatever form the front end does actually use to do the legitimate expected vtable pointer changes, middle-end optimizations thereof?
>
>

any transformation that the middle-end does not be on the basis that it does
not change the observable semantics.  So, it can take advantage of any
special encoding used by the front-end as long as the semantics is preserved.

>  - Jay
>
>