`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.
