This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]