Make -linkonce-templates *not* tamper with the general template
emission algorithm anymore (so on top of default non-allinst or
-allinst modes), and keep those tweaks as experimental
-linkonce-templates-aggressive.
Compiling the druntime/Phobos unittests is only marginally slowed
down compared to the more aggressive variant (~1.5% for debug,
~2.5% for release). It does show some rough 10% increase in required
memory, but that's in line with non-linkonce-templates.
The more aggressive variant has the advantage of skipping
needsCodegen() and potentially codegen'ing less symbols. The problem
is that if an instantiated symbol isn't explicitly referenced, for
instance a CRT ctor, it might not be codegen'd at all.
The linkage now (2.098) also affects the size of empty structs - e.g.,
1 for extern(C++), 0 for Posix extern(C), 4 for MSVC extern(C).
This also affects beauties like `extern(C) struct S { double[0] a; }`,
as tested by dmd-testsuite's runnable/ldc_cabi1.d, which is hereby
fixed for Posix - don't try to GEP into an empty LL struct.
A clean way of directly accessing struct and class init symbols. It
yields a `const(void[])` slice; the length reflecting the struct/class
instance size, and the pointer either pointing to the init symbol or
being null for zero-initialized structs.
Paves the way for resolving #3773 in druntime as well as accessing class
init symbols without `TypeInfo_Class.initializer()` indirection, and so
with -betterC as well.
* Newly require `-link-defaultlib-shared` for implicit dllimport.
E.g., this enables to compile druntime DLL with `-fvisibility=public`
for pure exports and no (local) imports (such as builtin TypeInfos).
* `-link-defaultlib-shared` alone now only implicitly imports symbols
from druntime/Phobos.
This simplifies building complex DLLs linked against a bunch of
static libs (dub only supports static lib dependencies!); the static
libs don't need to be compiled with `-fvisibility=public` anymore
(if the DLL itself isn't either), `-link-defaultlib-shared` is
sufficient.
This is mainly useful for existing DLLs with explicit exports, to make
them link against *shared* druntime/Phobos and so end up with a single
druntime/Phobos for the whole process.
Init symbols, TypeInfos (classes only) & vtables - unless defined in a
root module. For explicitly exported aggregates, or, with
`-fvisibility=public`, all aggregates.
This fixes an issue where any instantiation of TypeInfo in the final
output would lead to a cryptic error with no file or line information.
This change brings ldc in line with dmd's reporting of the same error,
which at least gives file and line information to discover the problem.
As *the* way to access the IrType associated with a Type via its `ctype`
field. Most importantly, it makes sure all access is redirected to the
*unqualified* type's `ctype`, which allows to get rid of the 'multiple
types' workaround for aggregates in DtoType(). Those were e.g. hit for
`shared struct SpinLock`, where the struct's type includes the `shared`
modifier...
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.
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.
Analogous to ClassInfos, incl. normal linkage (external for non-
templates, weak_odr for templates).
This enables to get rid of frontend logic wrt. whether to add
TypeInfoStructDeclarations to a module's members tree - previously,
it was defined as linkonce_odr in the owning module and each referencing
module (unless speculative) - and related extra semantic and codegen for
the special member functions.
I've gone a bit further and moved the entire TypeInfo emission for LDC
to the codegen layer; no TypeInfoDeclarations are added to the module
members anymore. Whenever we need a TypeInfo symbol during codegen, it
is declared or defined, and we don't need to rely on brittle frontend
logic with speculative-ness complications.
This might slightly increase compilation speed due to less emitted
TypeInfos and functions (possibly less work for the linker too).
A slight drawback is that the job of stripping unused struct TypeInfos
is fully delegated to the linker, as the TypeInfo is guaranteed to end
up in the owning object file due to no linkonce_odr.
Another theoretical drawback is that the optimizer can definitely not
inline xtoHash/xopEquals/xopCmp/xtoString/xdtor[ti]/xpostblit function
pointer indirections in non-owning CUs without LTO (neither the pointers
nor the special member functions are defined anymore).
These (public) members are probably hardly used directly though, and
instead used by the virtual TypeInfo_Struct methods equals/compare/
getHash/destroy/postblit, which are exclusively defined in druntime's
object.o (incl. the TypeInfo_Struct vtable) and aren't cross-module-
inlined anyway (without LTO).
Re-emitting the struct TypeInfos (and optionally the special member
functions too) into each referencing CU could be handled in our codegen
layer, which should be much simpler and more robust than the upstream
scheme.
Fixing a regression in dmd-testsuite's compilable/test8543.d, where CTFE
changes seem not to consider such previous LDC-specific CastExp as lvalue
anymore.
Previously, the static-array alloca wasn't suitably aligned for the
store instruction, which uses the greater vector alignment.
This has surfaced now with LLVM 11 on Win32 - this fixes dmd-testsuite's
runnable/ldc_llvm_inline_ir.d.
