Re: C++ virtual function calls (David L Moore)
Sat, 14 Oct 1995 16:16:30 GMT

          From comp.compilers

Related articles
C++ virtual function calls tim@franck.Princeton.EDU (1995-09-29)
Re: C++ virtual function calls (1995-10-05)
Re: C++ virtual function calls (1995-10-14)
Re: C++ virtual function calls (1995-10-23)
Re: Re: C++ virtual function calls egouriou@CS.UCLA.EDU (Eric Gouriou) (1995-10-23)
Re: C++ virtual function calls (1995-10-25)
Re: C++ virtual function calls (1995-10-30)
Re: C++ virtual function calls (John B. Plevyak) (1995-11-09)
Re: C++ virtual function calls (1995-11-05)
[4 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers
From: (David L Moore)
Keywords: C++, optimize
Organization: Netcom
References: 95-10-029
Date: Sat, 14 Oct 1995 16:16:30 GMT

> I was writing some C++, and in the middle of a tight loop, had
> something like:
> Base *foo = ...;
> for (...) {
> foo->virtual_method(...);
> }
> Are compilers smart enough to lift the virtual lookup out of the loop?
> Is this commonly done?

Most compilers that are any good should be hoisting this out of the loop. I
would certainly consider it a bug if a compiler doesn't. Such a bug could
come about because the implementor had dedicated an intermediate language
opcode to the operation (rather than spelling out the operation as a load
and call-register-indirect) but would more likely mean that the compiler
did a very poor job of hoisting generally.

A related but much more interesting problem is this:

          Given a loop with several virtual function calls:

              while (1) {

When is it worthwhile hoisting the dispatching out of the loop and inlining
the loop? That is, you turn the loop into a virtual function so that the
virtual calls inside the loop can be statically bound and then pulled inline.

You need one for every type that can appear, so you probably want a fall back
function which just does the regular dispatching and there is some interesting
book-keeping to take care of as a type's virtual table is now dynamic rather
than static. Also, you probably want to drive this from a profiler which can
give statistics on what types were present at any point in the code rather than
just what code was executed.

Clearly, a lot of work for one optimization, but the speed-ups could be

(I threw in y so you can work on dynamic typing algorithms while
pretending to do optimization - if you only want to support single
dispatching you need to prove y is an x or else not pull that inline)

I have not seen any discussion of this in the literature. Indeed, I suspect
optimization of C++ is still a largely untapped field.

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.