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
By separating the "use this compiler" configuration from other items,
we avoid redundancies, and at the same time simplify how the aarch64
variants are configured by having the $os_variant.json files only
contain the `target`.
Overall, each build now only uses at most 4 configs:
- one for the compiler it uses
- one for the target (optional when the host is the same as the target)
- one for the patches applied to the clang/llvm source
- one for the build type (stage-1, profile or stage-4-pgo)
And a similar pattern for clang-tidy.
Also remove the setting for ld, which hasn't been used since bug
1799423, and ranlib and ar for builds using clang-cl, as it's not used
either.
Differential Revision: https://phabricator.services.mozilla.com/D220652
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
Before trying to address the issue in depth (possibly backporting an
upcoming llvm-config change), let's just revert to something that is
known to work for the moment.
Differential Revision: https://phabricator.services.mozilla.com/D213529
This has the potential to regress other things, and if that happens,
we'll balance the pros and cons. But first, let's attempt this.
Differential Revision: https://phabricator.services.mozilla.com/D212516
They existed to revert things that conflicted with other things being
reverted, but those things are not reverted anymore as of bug 1892128.
Differential Revision: https://phabricator.services.mozilla.com/D211807
Reverting the entire commit that is causing problems has caused a number
of conflicts with further changes in LLVM in the past year and a half,
making us have to revert a bunch of other patches.
Instead of doing that, we just revert the small part of the original
change that is causing the problem, avoiding conflicts with newer
changes. This also gives us a better hint at what's really going on.
Differential Revision: https://phabricator.services.mozilla.com/D207829
We're currently applying patches to clang to work around some yet
unidentified problem with some change that, when applied to
llvm-symbolizer, makes tsan tests timeout for some reason.
Those patches regularly conflict with newer changes to LLVM, blocking
the clang build. We however actually don't need to apply these reverts
to clang itself, only to llvm-symbolizer, which we build separately. So
we do that, and fix the llvm-symbolizer-trunk task to revert the new
conflicting upstream patches.
Differential Revision: https://phabricator.services.mozilla.com/D206727
We're currently applying patches to clang to work around some yet
unidentified problem with some change that, when applied to
llvm-symbolizer, makes tsan tests timeout for some reason.
Those patches regularly conflict with newer changes to LLVM, blocking
the clang build. We however actually don't need to apply these reverts
to clang itself, only to llvm-symbolizer, which we build separately. So
we do that, and fix the llvm-symbolizer-trunk task to revert the new
conflicting upstream patches.
Differential Revision: https://phabricator.services.mozilla.com/D206727
We're currently applying patches to clang to work around some yet
unidentified problem with some change that, when applied to
llvm-symbolizer, makes tsan tests timeout for some reason.
Those patches regularly conflict with newer changes to LLVM, blocking
the clang build. We however actually don't need to apply these reverts
to clang itself, only to llvm-symbolizer, which we build separately. So
we do that, and fix the llvm-symbolizer-trunk task to revert the new
conflicting upstream patches.
Differential Revision: https://phabricator.services.mozilla.com/D206727
It's not like we publish the ReleaseNotes from the clang toolchain
artifact, and it's only going to be a recurrent source of patch conflict
when the upstream release notes change.
Differential Revision: https://phabricator.services.mozilla.com/D196529
Some more recent fixes upstream unbroke cross-compiling the windows
compiler-rt, so we don't need the reversal patch anymore. We also don't
need it on clang 14 either because we don't build the windows
compiler-rt there.
Differential Revision: https://phabricator.services.mozilla.com/D189881
Noemi Erli
Mike Hommey
Kagami Sascha Rosylight
Cristian Tuns
Cristina Horotan
Ryan VanderMeulen
acseh
Andrew Halberstadt
Stanca Serban
Norisz Fay
Iulian Moraru
Nazım Can Altınova
Mike Hommey
serge-sans-paille