Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!uunet!microsoft!jimad
From: jimad@microsoft.UUCP (Jim ADCOCK)
Newsgroups: comp.lang.c++
Subject: Re: Efficient compilation of virtual functions
Message-ID: <56970@microsoft.UUCP>
Date: 27 Aug 90 21:05:56 GMT
References: <1990Aug22.193347.18486@ux1.cso.uiuc.edu> <6428@wolfen.cc.uow.oz> <1311@lupine.NCD.COM>
Reply-To: jimad@microsoft.UUCP (Jim ADCOCK)
Organization: Microsoft Corp., Redmond WA
Lines: 26

In article <1311@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes:
>Note however that in the example given by Taed, the pointer variable in
>question was local to the function, and a simple bit of data flow analysis
>could have helped the compiler to establish (unambiguously) that the given
>pointer variable would *never* take on a value which pointed to any "more
>derived" class.
>
>Many (most?) optimizing compilers do perform at least some flow analysis,
>so it would seem that de-virtualizing some calls on some virtual functions
>should be both possible and reasonable.

An obvious first step is to get compilers to understand that operator new
really is a special member function, so that in the common case of:

	BASE* pb = new DIRV;

new is known by the compiler to return a ptr to an object of exactly DIRV type.
Compilers need to understand that special member functions are special, and
not just some other function.

Another "obvious" optimization that "C++" compilers need to understand is
the difference between stack and heap, so that this==0 ? type tests are
not generated for objects created on the stack.  Surprisingly, many C 
compilers do not recognize that objects on the stack must not have null
addresses.  Again, C++ optimization issues are different from C optimization
issues.