Extend -linkonce-templates by matching template emission scheme #3600
Conversation
|
@kinke Let me know when this is ready to be tested on Weka's codebase. |
|
It should be ready, first tests results looking good (benign failures after a quick glance). [It currently defaults to |
|
Sorry, there was still a problem for unreferenced symbols like module ctors, fixed now. Only 2 failing tests here; lit-test |
kinke
force-pushed
the
linkonce2
branch
2 times, most recently
from
8e46911 to
14a91e0
Compare
kinke
changed the title
I.e., *define* templated symbols in each referencing compilation unit when using discardable linkonce_odr linkage, analogous to C++. This makes each compilation unit self-sufficient wrt. templated symbols, which also means increased opportunity for inlining and less need for LTO. There should be no more undefined symbol issues caused by buggy template culling. The biggest advantage is that the optimizer can discard unused linkonce_odr symbols early instead of optimizing and forwarding to the assembler. So this is especially useful with -O to decrease compilation times and can at least in some scenarios greatly outweigh the (potentially very much) higher number of symbols defined by the glue layer. Libraries compiled with -linkonce-templates can generally not be linked against dependent code compiled without -linkonce-templates; the other way around works.
This fixes a few test regressions caused by missing non-referenced module ctors, e.g., inside a templated struct, which requires full codegen of the whole StructDeclaration and where define-on-declare of individual member functions etc. doesn't work. Keep the existing logic to determine the actual root module the primary instance will be assigned to.
The semantics were almost identical, except for DtoIsTemplateInstance()
checking the specified Dsymbol and its parents, while isInstantiated()
starts from its parent and ignores the symbol itself.
After a quick glance, we seem to have fed it with {Aggregate,Func,Var}
Declarations only, so should be fine with the default front-end variant.
…unittests & dmd-testsuite (release)
|
I've enabled Some rough timings (only 1 run) and static unittest lib sizes compared to master, using LLVM 11 without assertions on Win64 on my personal quad-core:
This is in line with some early tests in #3422. The fact that each unittest lib is smaller than before, including the debug ones without any optimization, shows that the normal template emission for |
|
Nice, maybe ping @atilaneves and maybe align this up with what he's doing for dmd? |
[In essence, a revised version of the remaining stuff from #3422.]
I.e., define templated symbols in each referencing compilation unit (=> object file) when using discardable
linkonce_odrlinkage, analogous to C++.This makes each compilation unit self-sufficient wrt. templated symbols, which also means increased opportunity for inlining and less need for LTO. There should be no more undefined symbol issues caused by buggy template culling.
The biggest advantage is that the optimizer can discard unused
linkonce_odrsymbols early instead of optimizing and forwarding to the assembler. So this is especially useful with-Oto decrease compilation times and can at least in some scenarios greatly outweigh the (potentially very much) higher number of symbols defined by the glue layer.Libraries compiled with
-linkonce-templatescan generally not be linked against dependent code compiled without-linkonce-templates; the other way around works.