Starting with LLVM 3.7, linkage and COMDAT are 2 different concepts.
This means that LinkageODROnce does not put the object into a COMDAT.
On Windows this resulted in linker error messages.
This PR places all template functions, TypeInfo objects and other
objects into a COMDAT.
Includes all tagged with v2.067.0-b2. Does not includes latest druntime changes from ldc (head) branch.
This is known to be broken. I only merged the frontend stuff but did not try to compile something...
First merge of current development stream. Asm blocks are known to be broken.
DMD: 0c9f437bc24015707130ba42dc434d9cd58282fb
druntime: 86d49cfb3670904603df0cfdfe44c6fff565c0fc
Phobos: a8ca4f7964becac680af0eadbde05aa7d10fc338
Since the change to the symbol emission strategy, a lot of the
previous attempts to derive the linkage for a symbol from its
AST node has been superfluous. This cleans up all the related
code, as it is really not doing much anymore.
The code to opportunistically internalize symbols is now gone
entirely. It was commented out anyway due to problems with
making it work reliably in the face of the not-so-stable
structure of the AST we get from the frontend (regarding the
modules certain symbols end up in). But in any case internal
linkage woudl also be troublesome for cross-module inlining,
so I gave up on making this work for the time being.
The only (minor) change in the emitted code should be in
.offTi generation, which is untested and disabled by default
anyway (GENERATE_OFFTI).
Turns out that since the change to use DMD's symbol emission
logic a few releases back we didn't actually ever emit code
for the extra modules. Thus, all the effort for the extra
semantic passes went to waste.
If we want to implement DMD-style cross-module inlining, we
need to add the extra semantic3s back in, and then iterate
over all the non-root modules with a codegen visitor that
only emits symbols as available_externally.
We probably won't need the availableExternally members if
we start with a clean design in the new symbol emission
framework. Thus, remove everything in the meantime. This
will make some release builds a bit faster, and should not
negatively affect generated code.
The remaining ones should also be easy to remove with a
closer look at the situation.
Ideally, we would get rid of all of them at some point and
use safe wrapper functions for accessing the IrDsymbol
associated with a given declaration (which would emit the
declarations on the fly if not already present).
This commit fundamentally changes the way symbol emission in
LDC works: Previously, whenever a declaration was used in some
way, the compiler would check whether it actually needs to be
defined in the currently processed module, based only on the
symbol itself. This lack of contextual information proved to
be a major problem in correctly handling emission of templates
(see e.g. #454).
Now, the DtoResolve…() family of functions and similar only
ever declare the symbols, and definition is handled by doing
a single pass over Module::members for the root module. This
is the same strategy that DMD uses as well, which should
also reduce the maintainance burden down the road (which is
important as during the last few releases, there was pretty
much always a symbol emission related problem slowing us
down).
Our old approach might have been a bit better tuned w.r.t.
avoiding emission of unneeded template instances, but 2.064
will bring improvements here (DMD: FuncDeclaration::toObjFile).
Barring such issues, the change shoud also marginally improve
compile times because of declarations no longer being emitted
when they are not needed.
In the future, we should also consider refactoring the code
so that it no longer directly accesses Dsymbol::ir but uses
wrapper functions that ensure that the appropriate
DtoResolve…() function has been called.
GitHub: Fixes#454.
This is just to improve clarity, as it was rather non-obvious
what of the code also applied to classes before.
IrTypeAggr::createInitializerConstant would currently belong in
IrTypeStruct, but this will be refactored anyway.
This might have been required with the old (pre-3.0) LLVM
type system, but the module linker handles global type
resolution just fine now.
Also, it is virtually impossible to determine the type in
advance for some cases, e.g. an array of unions with an
initializer that contains pointers to the array itself.
