Benchmarks on CI show that there are some performance regressions after
LLVM update due to worse inliner results. Explicit specification of
target-features fixes the problem. Interestingly, it seems that this is
not required for Darwin AArch64 target.
Clang-produced and GCC-produced binaries might be ABI-incompatible on
MinGW. Explanation on GitHub: msys2/MINGW-packages/issues/6855#issuecomment-680859662.
TL;DR: GCC-generated sections are 16-byte-padded, while Clang ones are
not. It causes problems during merge of COMDAT sections.
I observed the problem during compilation of runtime tests, but it is
possible that the problem could affect main compilation pipeline as well.
https://reviews.llvm.org/D86659 (which landed in LLVM 12) fixes
the problem. So we have another motivation for switching to LLD besides
https://youtrack.jetbrains.com/issue/KT-47605.
The only known downside is unsupported defsym which causes slight binary
size increase. I think it is doable.
The right way is to add something like KonanTarget.MSVC_X64, but doing
so requires changes throughout whole compiler. It would be especially
painful in HostManager, where we would need to deprecate
KonanTarget.MINGW_X64 as host. Instead we "hack" ClangArgs to compile
for x86_64-pc-windows-msvc instead of x86_64-pc-windows-gnu in JNI case.
CI may contain custom MSVC and Windows Kit installation path, so we
should support it. Things might break when machine has several MSVC
installed (at custom and default path), but it sounds more like
incorrect environment setup problem than ours.
--no-threads flag was used, because LLD had deadlock long time ago.
This flag is removed from LLD (in favor of --threads=N) and it looks
like that the bug is gone now. So we can just drop --no-threads flag!
This commit is important for several reasons:
1. Finally, LLVM update from 8.0.0 to 11.1.0
At the time of writing, LLVM 12.0.0 already came out, but we need to be
compatible with LLVM from Xcode 12.5, so that's why we stick to a bit
older version of LLVM.
2. These LLVM distributions are built with tools/llvm_builder/package.py
We finally managed to introduce an explicit process of building our LLVM
distributions, so we will be able to updated them more frequently and
adapt to our needs.
3. Native Windows LLVM instead of MinGW
Last but not least, we now use native Windows LLVM distribution. While
it might be harder to use (no more posix everywhere), simpler build
process (building msys2 is not that easy) and no need for MinGW-specific
patches makes such distribution way more convenient.
The next LLVM version will be 11.1.0, and we need to be sure that
Xcode supports bitcode of this version. So we bump minimal Xcode version
to 12.5, which should be OK, because by the time Kotlin 1.6.0 comes out,
Xcode 12.5 will be around 6 month old.
Also this commit simplifies tarball naming.
We are going to switch to LLD linker for MinGW targets.
Right now LLD for MinGW doesn't support all features
of ld.bfd and thus this change might be breaking for some users.
To make transition smoother, we run lld -### to show a warning to user
so they can update their compilation options before LLD will be turned
on by default.
More details: https://youtrack.jetbrains.com/issue/KT-47605
Create an explicit list of targets that have unstable compiler caches
in konan.properties. It allows to control all lists of cacheable targets
in a single place.
Target triple (like `arm64-apple-ios-simulator`) is a common
way to represent any target platform.
One of many useful properties: it allows to explicitly
distinguish iOS arm64 simulator target and a real device.
Technically, it is a dependency of a compiler itself.
Thus, we can simplify konan.properties a little bit
by applying the same approach as we did for LLVM.
When building an optimised release dynamic framework we see a lot of local symbols in Mach-O. When calling `strip -x` this can be dramatically reduced whilst still having a usable artefact.
Current logic seems to keep symbols for DSYM extraction in debug light mode. But only strips hardcoded debug symbols (`strip -S`) afterwards.
Introduce new stripFlags for Apple compilation to allow optimization for release with DSYM builds
lld is doing something wrong for linux_arm32_hfp and linux_arm64 targets, so we fallback to gold linker on Linux and Windows.
See KT-41725 and KT-42446
Sergey Bogolepov