Re: C++ virtual function calls

cliffc@ami.sps.mot.com (Cliff Click)
Thu, 5 Oct 1995 22:03:11 GMT

          From comp.compilers

Related articles
C++ virtual function calls tim@franck.Princeton.EDU (1995-09-29)
Re: C++ virtual function calls cliffc@ami.sps.mot.com (1995-10-05)
Re: C++ virtual function calls dlmoore@ix.netcom.com (1995-10-14)
Re: C++ virtual function calls genew@mindlink.bc.ca (1995-10-23)
Re: C++ virtual function calls cliffc@ami.sps.mot.com (1995-10-25)
Re: C++ virtual function calls joe@sanskrit.ho.att.com (1995-10-30)
Re: C++ virtual function calls jplevyak@violet-femmes.cs.uiuc.edu (John B. Plevyak) (1995-11-09)
Re: C++ virtual function calls cliffc@ami.sps.mot.com (1995-11-05)
[4 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers
From: cliffc@ami.sps.mot.com (Cliff Click)
Keywords: C++, optimize
Organization: none
References: 95-10-029
Date: Thu, 5 Oct 1995 22:03:11 GMT

tim@franck.Princeton.EDU (Tim Hollebeek) writes:


> Base *foo = ...;
>
> for (...) {
> foo->virtual_method(...);
> }
>
> Are compilers smart enough to lift the virtual lookup out of the loop?


Well...
I'd like to say yes, but I'm not holding my breath.
If your compiler lowers the IR to loads & stores before doing code
hoisting, and it tags the vtable pointer as being a pointer to
constant memory then everything should fall out in the wash.
That's a lot of IF's. (oh yeah, foo has to const in the loop as well,
or all bets are off - and how is the compiler gonna know that?)




> Is this commonly done? It seems like an easy optimization, but I'm
> not sure if I'm missing something, or if compiler writers are still
> too busy implementing partially specialized virtual template functions
> that throw templated exception classes based on RTTI info.


You speaketh too much truth here...


Cliff
--
Cliff Click Compiler Researcher & Designer
RISC Software, Motorola PowerPC Compilers
cliffc@risc.sps.mot.com (512) 891-7240
--


Post a followup to this message

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