`llvm::AttrBuilder` was changed to require an LLVMContext in its constructor, and can no longer be copied.
declare `DEBIG_TYPE` after includes for the GC2Stack pass as `llvm/Support/GenericDomTreeConstruction.h `(included from `llvm/IR/Dominators.h` `#define`s and `#undef`s it.
`llvm::DIBuilder::createExpression` now takes an `ArrayRef<uint64_t>` instead of `int64_t`. EmitLocalVariable has similarly changed
As cloning a function with debuginfos has always been problematic,
and I haven't found a suitable workaround for new assertions with
LLVM 13, without resorting to even blunter instruments like
suppressing debuginfos for weak-any functions and MSVC targets.
* Improve ftime-trace implementation.
- Rewrite ftime-trace to our own implementatation instead of using LLVM's time trace code. The disadvantage is that this removes LLVM's work from the trace (optimization), but has the large benefit of being able to tailor the tracing output to our needs.
- Add memory tracing to ftime-trace (not possible with LLVM's implementation)
- Do not output the sum for each "category"/named string. This causes the LLVM output to be _very_ long, because we put more information in each time segment name. Tooling that processes the time trace output can do this summing itself (i.e. Tracy), and makes the time trace much more pleasant to view in trace viewers.
- Use MonoTime, move timescale calculation to output stage, 'measurement' stage uses ticks as unit
- Fix crash on `ldc2 -ftime-trace` without files passed.
As there are apparently cases where the struct hasn't had semantic3
yet, at least with -linkonce-templates. This prevents erroneous xopCmp
etc. (failing to compile) from being referenced in the TypeInfo (=>
linker errors) / being analyzed for -linkonce-templates codegen.
`semanticTypeInfoMembers()` replaces them by `object._xopCmp()` etc.
if compilation fails.
To pave the way for simple DLL generation (end goal:
druntime-ldc-shared.dll).
The dllexport storage class for functions definitions is enough; the
automatically generated import .lib seems to resolve the regular symbol
name to the actual symbol (__imp_*), so dllimport for declarations seems
superfluous.
For global variables, things are apparently different unfortunately.
This uses LLVM's TimeProfiler functionality, such that LLVM's work is traced in the same profile (optimization and machine code gen).
Functionality is meant to be identical to Clang and LLD's --ftime-trace.
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.
LLVM already provides suited RAII helper types to restore the IRBuilder
state. [They sadly aren't movable, so I've had to wrap them in a
unique_ptr.]
While at it, also minimally revise debuginfo generation for functions.
Which supports more cmdline options in the meantime than what we have
been supporting manually, and should be future-proof, similar to
InitTargetOptionsFromCodeGenFlags().
Attributes are only set if explicitly specified in the cmdline (and not
already present in the function's existing attributes).
This started out as a workaround for not being able to determine whether
the user has explicitly set -frame-pointer in the cmdline with LLVM 11,
and ended with having to touch more than I wanted. An *enabled*
-ffast-math flag (from us, not LLVM) overriding LLVM's
-enable-unsafe-fp-math, but e.g. -ffast-math=false NOT overriding was/is
one of the quirks.
Replace the stack of IRScopes, each with its own IRBuilder, by directly
tampering with the state of a single IRBuilder.
This seems like the most feasible way to account for a breaking change
in LLVM 11, disallowing IRBuilder from being copied.
This is exactly what happened for the 4 problematic delegate literals
for the Phobos unittests - DtoDefineFunction(fd) could result in that
definition ending up as available_externally - all done as part of
DtoResolveFunction(), which declared it, and DtoDeclareFunction()
defined it as available_externally, and the outer DtoDefineFunction()
returned early in that case without fixing up the linkage.
Previously, the logic gave up early if semantic3 was run for the
function to be inlined, either because the function is going to be
codegen'd in some root module, or because sema3 was already run for an
available_externally 'copy' in a previous compilation unit.
This restricted a function to being defined in at most one compilation
unit per ldc2 invocation.
So e.g. a little `pragma(inline, true)` wrapper in druntime wasn't
inlined into other druntime modules, because the whole lib is built in a
single cmdline by default, and sema3 was obviously run for the actual
emission in the corresponding object file.
When later compiling Phobos in a single cmdline, only the first object
file referencing the wrapper got lucky, running sema3 manually and
getting an available_externally 'copy'.
