llvm dev - Apr 2008 - [LLVMdev] Virtual methods (was: LLVMBuilder vs LLVMFoldingBuilder)

Am Donnerstag, den 03.04.2008, 19:29 -0700 schrieb Chris
Lattner:
> On Apr 2, 2008, at 9:54 AM, Dominic Hamon wrote:
> 
> > Would it be reasonable for me to submit a patch whereby [...] the
> > LLVMFoldingBuilder methods become virtual overrides of the base
> > class methods?
> 
> 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.

Does such an approach make sense with LLVM?
(I'd want to do such things for my personal language project, so the
answer would be affecting compilation strategy.)

Regards,
Jo

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.

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/

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