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

[Jay K]

----------------------------------------
> 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.
 (in C++, not Java)
However, is the compiler not obligated to let me pound on random memory through casting, memcpy, etc.?
Including copying vtable pointers from one object/type to another?
Or perhaps it isn't?
 
 
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?
 
 
 - Jay