On Friday, 7 June 2013 at 01:32:17 UTC, Manu wrote:
IIRC, GCC requires explicit support for LTO in the backend,
which means
minority architectures will probably never get support, and
these are the
ones that need it the most.
Don't know about LLVM, but I'll bet again, the minority
architectures will
not have good support.
LTO is done y dumping the IR in the object file. The codegen
occurs after LTO if they are enabled.
And there's still the DLL case.
You can't simply compare the relative cost of a DLL call and a
virtual call
(although a DLL call is still slightly less work than a virtual
call).
The only difference is the indirect branch. In both cases the
compiler is blind, so it will be slow. You are right, the
indirect branch is an additional cost.
In the case of a static call, you can expect the call to be
several time faster, when you'll only get a marginal improvement
on shared object.
The real issue is though, that code within your program which
IS subject to
LTO still can't have a de-virtualisation optimisation applied
anyway, since
it can't know if a DLL might introduce a new derived class.
The possibility of a DLL simply existing means such an
optimisation can't
be performed, even if it is possible.
This is why I'm proposing for the nth time that virtual is
enforced by the compiler. And yes, this can be done by setting
the visibility of class's typeid (so overriding a class that
isn't exported is a link time error).
