search for: nonvirtual

...> This is very interesting. If there is a use-case that this sort of > thing would strongly benefit, then we could add it. Any tight loop that uses a virtual function. That's interesting for languages where functions are virtual by default. (I think OO language designers tend to avoid nonvirtual functions in general.) Note that functional language tend to have the moral equivalent of virtual functions, too, but I don't know how strong the effect would be. Regards, Jo

...g. If there is a use-case that this sort of >> thing would strongly benefit, then we could add it. > > Any tight loop that uses a virtual function. > That's interesting for languages where functions are virtual by > default. > (I think OO language designers tend to avoid nonvirtual functions in > general.) This isn't safe in C++ for example. Also, the proposed definition wouldn't permit hoisting one of these loads out of a loop. -Chris

...adjusted, i32 1, i32 2), !prof !8 with: !{!"indirect_call_targets", i64 1, !"_ZN1A8test_subEii", i64 1} in function: _Z8testmainM1AFiiiE CS hotness% = 1.000000e+02 Target hotness% = 100 == Basic Block Before == memptr.end: ; preds = %memptr.nonvirtual, %memptr.virtual %5 = phi i32 (%class.A*, i32, i32)* [ %memptr.virtualfn, %memptr.virtual ], [ %memptr.nonvirtualfn, %memptr.nonvirtual ] %call = call i32 %5(%class.A* %this.adjusted, i32 1, i32 2), !prof !8 ret i32 %call ... !8 = !{!"indirect_call_targets", i64 1, !"_ZN1A8test_...

On May 13, 2008, at 4:09 PM, Gordon Henriksen wrote: > On May 13, 2008, at 18:28, Dan Gohman wrote: > >> On May 12, 2008, at 6:49 PM, Talin wrote: >> >>> So the question is, what's the trade-off. In most languages that >>> support exceptions, you tend to think of exceptions as expensive >>> operations that should only be thrown if something truly

...guages, 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 do it). In C++, integer-to-pointer tricks and array indexing via pointers could make alias analysis more difficult. Is it that much harder that the percentage of call sites to replace with static calls drops significantly? I agree with (b). I agree with th...

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)

On May 13, 2008, at 18:28, Dan Gohman wrote: > On May 12, 2008, at 6:49 PM, Talin wrote: > >> So the question is, what's the trade-off. In most languages that >> support exceptions, you tend to think of exceptions as expensive >> operations that should only be thrown if something truly >> "exceptional" happens. OTOH, the Java case is also made

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