This matches what is done in build-all.sh for the PGO step; this
removes rather large (~50 MB) libraries that mostly are needed
for compiling for the host unix platforms. (On Linux it's needed
if building with profiling, on macOS it's needed for the builtin
functions for platform version availability too.)
This matches what is done for the regular builds; we run (build-only)
tests already with the first cross compiler toolchains, not needing
to wait for the cross compiled toolchains to run on Windows.
This is required for properly formatting long doubles on x86
with UCRT (which doesn't use the mingw builtin printfs by default).
This fixes running the LLVM testsuite on x86 after commit
9bf7d04c4386daf1ef0acf95782a59855c98474a in llvm-project.
Relevant changes include:
- Lots of work for supporting ARM64EC and ARM64X
- LLD now produces more compact string tables in executables (only
relevant when including debug symbols)
- llvm-rc now supports multiplication/division expressions, like GNU
windres
- Improved support for armv7 and aarch64 in libunwind (for Itanium
ABI "forced unwinding", which I'm not aware of being used in
practice anywhere)
- Made the libunwind, libcxxabi, libcxx and compiler-rt tests pass on
armv7 and aarch64 mingw
- Made the llvm/clang tests pass on aarch64 mingw
The ARM github actions runners now run on Windows 11 10.0.26100,
which no longer support executing armv7 binaries. (Previously they
were running Windows 11 10.0.22631.)
If using Clang from /usr/bin, this makes it clear to CMake to use
$HOST-strip, as it otherwise may pick plain /usr/bin/strip, which
may not be able to strip the cross built executables.
CMAKE_ASM_COMPILER is set implicitly from CMAKE_C_COMPILER,
but the target flags aren't implied in the same way.
This fixes cross compiling LLVM with clang for an x86_64 target.
This wasn't an issue when cross compiling LLVM with clang for an
aarch64 target, because the BLAKE3 aarch64 SIMD is in the form
of a C file (with intrinsics), not a standalone .S file.
In this case, we want to incrementally build the remaining tools,
not do a full build. In case someone runs build-all.sh with CLEAN
set, the --macos-native-tools invocation of build-llvm.sh shouldn't
wipe the build directory.
This reverts commit 9e628b0f2d.
If LLVM was built with --disable-dylib, then the individual
LLVM libraries may expose a dependency on zlib. By restricting
the lldb-mi build to detect dependencies outside of $LLVM_DIR,
the build of lldb-mi fails to find zlib, making it impossible to
find all the necessary dependencies, ending up with errors like this:
CMake Error at llvm-mingw/llvm-project/llvm/build-asserts/lib/cmake/llvm/LLVMExports.cmake:55 (set_target_properties):
The link interface of target "LLVMSupport" contains:
ZLIB::ZLIB
but the target was not found. Possible reasons include:
* There is a typo in the target name.
* A find_package call is missing for an IMPORTED target.
* An ALIAS target is missing.
Revert this change for now, to allow building lldb-mi against
a non-dylib build of LLVM.
This makes the docker image contain a PGO optimized compiler,
without needing to redo all of the PGO build stages in docker.
This reverts commit 8f42112719,
and fixes building the multiplatform image in a simpler way.
Instead of doing two separate builds, with separate Dockerfiles,
just do one multiplatform build of one Dockerfile, which
docker runs serially, for each one of the included architectures,
just packaging the prebuilt toolchains in the docker image.
Using Frontend instrumentation rather than IR. This gives less
total speedup, but makes the profile much more usable for cross
other build targets.
Build the full Linux toolchain in stage1; this avoids needing to
rebuild runtimes for doing the profiling in stage2, and avoids
needing to wait for stage3 to complete before cross building
for Windows.
Do the same as when cross compiling; disallow detecting dependencies
outside of the given CMAKE_FIND_ROOT_PATH. Don't export LLVM_DIR
as we no longer need to pass it implicitly that way.
This makes the errors clearer, if LLVM isn't found where expected,
instead of misdetecting it from a different installation of LLVM
in the system.
If lldb-mi would try to find other optional dependencies, they would
no longer be found; this was already the case when cross compiling
though.
As build-llvm now can create a larger variety of build dir names,
enumerating all possible suffixes becomes problematic (especially
as they don't necessarily appear in one canonical order).
Instead, iterate over potential matches. If cross compiling, it
is easy as we can require the directory to contain the expected
suffix. If not cross compiling, we have no explicit suffix to look
for, but we can check that the directory doesn't match common
cross compilation triples.
Passing --instrumented=IR or --instrumented=Frontend builds
instrumented tool binaries. After running them and merging the
output profile files, run build-llvm.sh with
--profile=profile.profdata.
When cross compiling with llvm-mingw, we already implicitly use
clang and lld, but we don't need to specify these options as they
are set implicitly via the llvm-mingw wrappers.
Don't use tools from $PREFIX/bin automatically; this can be
confusing and problematic. If running with $PREFIX/bin in path,
the build at this stage gets reconfigured if rebuilding after
installing clang.
For multistage builds, install into separate toolchain
directories and add the right one to $PATH before invoking
build-llvm.sh. If one really wants to use the tools from $PREFIX
for a new build into the same directory, one has to add that
directory to the path manually.
Martin Storsjö