This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, PR 45934] Devirtualization aware of dynamic type changes
- From: Gabriel Dos Reis <gdr at integrable-solutions dot net>
- To: Jay K <jay dot krell at cornell dot edu>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>, hubicka at ucw dot cz, rguenther at suse dot de, mjambor at suse dot cz
- Date: Tue, 23 Nov 2010 17:22:59 -0600
- Subject: Re: [PATCH, PR 45934] Devirtualization aware of dynamic type changes
- References: <1290550442.11315.ezmlm@gcc.gnu.org> <COL101-W8F717C814522A83142FA9E63E0@phx.gbl>
On Tue, Nov 23, 2010 at 4:48 PM, Jay K <jay.krell@cornell.edu> wrote:
>
> Hm. Since the vtable pointer can change at almost any point,
> isn't the way to devirtualize, actually to check the vtable pointer
> for equality with one or a few common/expected values (possibly
> combined with profiling data as to the common values, though
> I find that very inconvenient personally...) and if equal,
> call the function directly, or more likely, inline it?
the vtable chaning happens during construction and destruction of
an object. It is not random.
>
>
>
> e.g.
> struct Base { virtual void F1() { printf("Base\n"); } };
> struct C1 : Base { C1() { }; virtual void F1() { printf("C1\n"); } };
> struct C2 : Base { C2() { }; virtual void F1() { printf("C2\n"); } };
> Base* b;
> b->F1();
> =>
> if (__likely(((void**)b)[-1] == &c1_vtable))
> ?fputs("C1\n", stdout);
> else call through the vtable?
>
>
>
> I realize it'd be nice to optimize further, but it isn't possible, right?
>
>
>
> If a "safe" language like Java is being compiled, you can presumbly
> be way less conservative (and in fact can/must immediately
> assume the vtable pointer is most derived, doesn't go through the
> steps like it does for C++). Is there a way to indicate that?
> "That" being what I don't have a technical definition of: "safety".
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.)