By doing so, we don't really need a stage 1 clang for mac and windows
(with the downside that the final PGOed clang becomes the
clang-toolchain artifact on those platforms), and cross-compiling stage
2 is much faster as a cross-compile, leaving only stage 3 to be native.
While here, for the one build type that still does stage 2 and 3 in one
task, we actually prefer taking the llvm-profdata from stage 1, as it
doesn't contain profile instrumentation (it should actually have been
this way since the beginning).
Differential Revision: https://phabricator.services.mozilla.com/D220654
This splits the clang build in the necessary steps to get native
profiles for Intel and Arm64 mac, similarly to Linux.
Stage 1s are cross-compiled, and the profile step runs natively.
Differential Revision: https://phabricator.services.mozilla.com/D220530
For now this uses Linux x64 profile for PGO as the macosx64-aarch64 task does, because we don't have aarch64 Windows worker now.
Differential Revision: https://phabricator.services.mozilla.com/D219012
Bug 1805664 had the side effect of installing terminfo libraries on the
toolchain docker image, which led to clang gaining a dependency on
libtinfo, leading to multiple failures, like PGO run jobs failing with
llvm-profdata failing to load the new dependency, or tsan tests failing
because llvm-symbolizer doesn't work because of the new dependency not
being fulfilled, which in turn breaks TSAN suppressions.
Differential Revision: https://phabricator.services.mozilla.com/D170417
These flags used to be necessary when we first were cross-compiling
clang, but more recent (although now old) changes have made them
actually unnecessary.
Differential Revision: https://phabricator.services.mozilla.com/D168033
These flags used to be necessary when we first were cross-compiling
clang, but more recent (although now old) changes have made them
actually unnecessary.
Differential Revision: https://phabricator.services.mozilla.com/D168033
Using ThinLTO because it's a good compromise between performance and
compilation speed.
Activating it for both profile generation and profile usage, doing it
only for profile usage leads to a lot of mismatch, aka
function control flow change detected (hash mismatch)
which leads to profile information not beoing used.
This requires using the whole llvm toolchain (lld, llvm-ar, llvm-ranlib)
from the same revision.
This is disabled on Windows where it causes link error on the LLVM
Plugin system.
Differential Revision: https://phabricator.services.mozilla.com/D162371
There are some ABI issues with libc++ headers in clang 15. The main
reason we are shipping libc++ with our clang is that the macos SDK,
up to and including 11.1, only contained the libc++ libraries, but
not the headers. The first SDK that contains the headers is 11.3
(there is no 11.2, at least publicly available), and we're now using
it.
Another problem with libc++ is that the way we currently build it is
deprecated and is going to yields hard errors soon enough on clang
trunk.
The simplest thing to do right now is to just stop shipping libc++.
Eventually, we may want to ship it correctly in a different way, for
all platforms, which was not happening anyways.
Differential Revision: https://phabricator.services.mozilla.com/D156283
Currently, when building clang for mac, which we cross-compile, we're
always passing a x86-64 target, even on arm64. This cancels out with the
LLVM build system adding `-arch arm64`, so it worked fine... until clang
15, where some things end up being built without `-arch arm64` and
things end up broken.
Differential Revision: https://phabricator.services.mozilla.com/D156258
There are a set of problems that arise from that setup that need to be
addressed before this can be enabled, but upstream is toying with it,
and it's better to have a setup that is stable rather than a setup that
can break when upstream changes something (which happened again earlier
today).
Differential Revision: https://phabricator.services.mozilla.com/D148625
Bug 1744890 moved build_libcxx out of the individual json configs, and
bug 1748056 made it always True. We can now remove it.
Differential Revision: https://phabricator.services.mozilla.com/D146873
While the llvm/cmake/platforms/WinMsvc.cmake file only supports
cross-compiles, it contains the right -fms-compatibility-version
to use to build clang/llvm (modulo when upstream forgets to update it).
It's better to rely on that, than to keep a version in build-clang.py
that would possibly need to cover multiple versions of clang.
Differential Revision: https://phabricator.services.mozilla.com/D143133
This improves out-of-the-box support for cross-compiles on tier-1 build
platforms, including for asan. This also reduces the number of different
*-cross toolchains we need for CI builds.
The linux clang is now also a repack, like the others, and the insertion
of the wasm compiler-rt is moved to the repack, which also allows to
remove that part of the build-clang.py script.
Differential Revision: https://phabricator.services.mozilla.com/D138749
Instead of building compiler-rt alongside clang, we reuse the clang
repack logic to put compiler-rts in place when building clang stage2
(which requires the profiling runtime).
The repack logic is unified to handle all platforms as well, and now
that compiler-rt is not built in clang, we also need to copy everything
that is not lib/* from the compiler-rt artifacts, so we now also ensure
that they're not diverging between those compiler-rt artifacts (except
for darwin libs, which need to be unified into universal libraries).
And as a bonus, we can also cross-build the mac clang toolchains with
the stage1 clang and the clang runtime for the target platform.
Differential Revision: https://phabricator.services.mozilla.com/D138748
This improves out-of-the-box support for cross-compiles on tier-1 build
platforms, including for asan. This also reduces the number of different
*-cross toolchains we need for CI builds.
The linux clang is now also a repack, like the others, and the insertion
of the wasm compiler-rt is moved to the repack, which also allows to
remove that part of the build-clang.py script.
Differential Revision: https://phabricator.services.mozilla.com/D138749
