-
-
Notifications
You must be signed in to change notification settings - Fork 267
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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 |
8e46911
to
14a91e0
Compare
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_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.