search for: smarteiffel

...gt; 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. I'm not sure how hard (a) really is. It's being done in other imperative OO languages, and quite successful there (the SmartEiffel folks have reported they can eliminate the vtable lookup in about 90% of call sites, reaping all the rewards of inlining etc. for these; you can assume that practically all functions in Eiffel are declared virtual, in fact you have to declare them nonvirtual if you want that and people almost never...

On Apr 4, 2008, at 3:59 PM, Joachim Durchholz wrote: > > I'm not sure how hard (a) really is. It's being done in other > imperative > OO languages, and quite successful there (the SmartEiffel folks have > reported they can eliminate the vtable lookup in about 90% of call > sites, Are those the folks that don't do separate compilation or dynamic libraries? :-)

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)

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