https://d.puremagic.com/issues/show_bug.cgi?id=12440
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #1 from [email protected] 2014-03-22 13:20:36 PDT --- (In reply to comment #0) > The idea is to examine the whole program's class hierarchies to determine > which > classes can be made final. Final classes can then benefit from non-virtual > dispatch of its virtual functions, and even inline them. Good. (But this can't solve the other problem listed by Manu and C# designers of virtual calls. It's not just a matter of performance). Beside finding what class/method can be final, whole program's class analysis can find what call points of _virtual functions_ always call the same method, so it can turn those virtual calls into non-virtual calls. Whole program's call analysis can also find what points call two different virtual methods. In such points the compiler can use a faster tiny (2-slots wide) inline cache and avoid the virtual call. Monomorphic and 2-polimorphic virtual call points cover a large percentage of all virtual call points (3-polimorphic and megamorphic call points are comparatively). So doing this you remove a significant percentage of all virtual calls. > Hence, to work, this would have to add a flag to the compiler, such as > -wholeprogram, that causes the compiler to make the assumption that all > classes > defined in files supplied to the compiler on the command line (not imports) > are > never derived from from other object files or DLLs. I suggest to avoid the "one trick pony" syndrome: "whole program" analysis is useful for some other purposes too (like executable libraries: http://rosettacode.org/wiki/Executable_library a pattern currently not supported in D. Or to support Link-time-optimization, etc), so perhaps it's a good idea to give a little stronger meaning to "-wholeprogram", so it's useful for more than just OO de-virtualization. > This could be implemented as a pass inserted before the inliner runs. > > Note that if the user throws this flag, and the assumption is not true, the > resulting program will behave badly in unpredictable ways. Is it possible to enforce/verify the condition and avoid such undefined situations? -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
