On Friday, 31 May 2013 at 09:43:05 UTC, Manu wrote:
- Require explicitly export when you want to create shared
objects.
This one is an enabler for an optimizer to finalize virtual
method. With
this mechanism in place, the compile knows all the override
and can
finalize many calls during LTO. I especially like that one as
it allow for
stripping many symbols at link time and allow for other LTO in
general (for
instance, the compiler can choose custom calling conventions
for some
methods, knowing all call sites).
The explicit export one have my preference, however, ti
require that
symbol used in shared lib are explicitly declared export. I
think we
shouldn't break the virtual by default behavior, but we still
need to
figure out a way to make thing more performant on this point.
You're concerned about the magnitude of breakage introducing an
explicit
virtual requirement. This would seem to be a much much bigger
breakage to
me, and I don't think it's intuitive.
Officially, we are just starting to support shared object. I know
you use them, and that this is a breakage to you. However, I
think it is reasonable to expect that most people do not. Still,
the migration should be carefully handled.
This change is actually a fairly big deal as it empower the
optimizer quite a lot, and not only for virtual functions. It can
do way more than the dev could manually annotating any function.
This is proven technology, not the sufficiently smart compiler
here. Ti be fair, I'd push for this change even if final was the
default, as it enable for many other optimizations.
As the example shown, manually annotating everything isn't going
to provide 5% to 7%, which irrelevant in most code path, and when
a compiler could improve the situation significantly
automatically.
