[LLVMdev] Virtual methods (was: LLVMBuilder vs LLVMFoldingBuilder)

[Jonathan S. Shapiro]

In general, the C++ compiler does NOT know the type of the leaf class
when performing a virtual method invocation. In particular, a parameter
(including "this") alleging to be a Foo* (Foo being some class) may
actually be any subclass of Foo, so unless the compiler can trace the
value flow all the way from the instantiation, it can't tell.

The necessary tracing is (a) hard, (b) whole-program, and (c) therefore
not supportable without a lot of linker support that isn't available in
practice.


On Fri, 2008-04-04 at 21:09 +0200, Joachim Durchholz wrote:
> Am Freitag, den 04.04.2008, 11:19 -0700 schrieb Chris Lattner:
> > On Fri, 4 Apr 2008, Joachim Durchholz wrote:
> > >> No, please don't do this.  The idea of llvmbuilder is that it is a
> > >> "free" wrapper around the other existing API calls.  Making the
> > >> methods virtual would make them much more expensive.
> > >
> > > Wouldn't the class of the objects be known at compile time in most
> > > cases? This is essentially just a case of precomputing constants, so I
> > > think this should be possible.
> > >
> > > If yes, the compiler can predetermine the type, hence the virtual method
> > > table that will be used, and can replace the virtual call with a static
> > > one.
> > 
> > Please verify that this actually happens in practice with llvm-gcc and 
> > gcc.
> 
> If that's already the case (which I'll gladly believe), where does the
> performance overhead for virtual functions come from?
> (Just curious.)
> 
> Regards,
> Jo
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev