The support introduced in 675702f356b0c3a540fa2e8af4192f7d658b2988 is
not working correctly in all scenarios. Instead of setup_host_tool
function, we can use the existing targets introduced by add_tablegen
macro.
When crosscompiling tools for a different architecture, we need to build
native libc-hdrgen which can be achieved using the existing CMake
support for crosscompiling tablegen tools.
Only some targets may be building llvm-libc in which case the top-level
LLVM_ENABLE_RUNTIMES variable won't contain libc. Rather, we can check
LLVM_ENABLE_PROJECTS since libc is required to be included there for
libc-hdrgen to be built (and when LLVM_ENABLE_RUNTIMES contains libc, we
automatically include libc in LLVM_ENABLE_PROJECTS as well).
We currently create a generic runtime target for all subbuilds. For
example if we're building libcxx for aarch64-linux-gnu and
x86_64-linux-gnu, we would create the cxx target that would depend on
cxx-aarch64-linux-gnu and cxx-x86_64-linux-gnu. The current
implementation creates the generic runtimes targets ahead of time which
introduces an issue where different subbuilds enable different runtimes.
We should instead create the generic targets as needed.
When a target sets LLVM_ENABLE_RUNTIMES, we should only generate proxy
targets for those runtimes rather than using the global list which may
contain runtimes that are not supported by that particular target.
This reverts commit 6403287eff.
This is failing on all but 1 of Linaro's flang builders.
CMake Error at /home/tcwg-buildbot/worker/clang-aarch64-full-2stage/llvm/flang-rt/unittests/CMakeLists.txt:37 (message):
Target llvm_gtest not found.
See discourse thread https://discourse.llvm.org/t/rfc-support-cmake-option-to-control-link-type-built-for-flang-runtime-libraries/71602/18 for full details.
Flang-rt is the new library target for the flang runtime libraries. It builds the Flang-rt library (which contains the sources of FortranRuntime and FortranDecimal) and the Fortran_main library. See documentation in this patch for detailed description (flang-rt/docs/GettingStarted.md).
This patch aims to:
- integrate Flang's runtime into existing llvm infrasturcture so that Flang's runtime can be built similarly to other runtimes via the runtimes target or via the llvm target as an enabled runtime
- decouple the FortranDecimal library sources that were used by both compiler and runtime so that different build configurations can be applied for compiler vs runtime
- add support for running flang-rt testsuites, which were created by migrating relevant tests from `flang/test` and `flang/unittest` to `flang-rt/test` and `flang-rt/unittest`, using a new `check-flang-rt` target.
- provide documentation on how to build and use the new FlangRT runtime
Reviewed By: DanielCChen
Differential Revision: https://reviews.llvm.org/D154869
Projects like libc++ include their own cache files, and it's convenient
to just be able to reuse those cache files as part of a runtimes build
instead of having to duplicate the settings inside a special runtimes
cache file (which will inevitably get out of sync).
I'm not completely happy about overloading the existing argument passing
behavior based on the argument name, but I also couldn't think of a good
alternative. Suggestions are welcome.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D158791
LLVM_TOOL_LLD_BUILD is a relic of the pre-monorepo times. This causes us to never set COMPILER_RT_HAS_LLD.
Instead, set it from the runtimes build if lld is being built and lld is used as the compiler-rt linker.
Mark a test that requires libstdc++ as requiring Android, as other platforms may not have a libstdc++ lying around.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D144660
LLVM_TOOL_LLD_BUILD is a relic of the pre-monorepo times. This causes us to never set COMPILER_RT_HAS_LLD.
Instead, set it from the runtimes build if lld is being built and lld is used as the compiler-rt linker.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D144660
Summary:
If the target for these tools doesn't exist we should simply assume that
they will be provided externally. This allows building `libc` standalone
with an external installation of `clang`.
The OpenMP offloading device runtime depends on multiple tools. We
should ensure that these tools are build before invoking the OpenMP
build.
Reviewed By: tra
Differential Revision: https://reviews.llvm.org/D147654
Currently, for BUILTIN_TARGETS and RUNTIME_TARGETS you can either use
the special "default" value, or a target triple.
For the "default" value, we don't set any target triple and passthrough
a subset of CMake variables into the subbuild. This is typically used
on Darwin where we build universal binaries and a single target triple
therefore isn't sufficient.
For the target triple value, you can set arbitrary CMake variables
through RUNTIMES_<target>_<variable>, but we always set target triple
to <target>. This gives more flexibility, because we can precisely
control what variables are set in the subbuild, but is unsuitable for
platforms like Darwin.
To address this, we would like to introduce a third option which is
similar to the second option, except we won't set target triple in
the subbuild (you can always do so yourself by setting the appropriate
CMake variable, e.g. RUNTIMES_<name>_CMAKE_C_COMPILER_TARGET=<triple>).
This change is a first step in that direction, by eliminating the support
of target triples from builtin_register_target and runtime_register_target
helper functions.
Differential Revision: https://reviews.llvm.org/D117263
Some configurations may require `-DCUDAToolkit_ROOT` to find CUDA
properly. This is currently not forwarded to the CMake invocation. This
patch adds a prefix so it will be visible when the runtimes build is
started.
Reviewed By: tra
Differential Revision: https://reviews.llvm.org/D147582
The `clang-offload-packager`. `nvptx-arch`, and `amdgpu-arch` tools are
required for building the GPU target of `libc`. This patch ensures that
we build this tool when directly building `libc` via `ninja libc` or similar.
Reviewed By: tra
Differential Revision: https://reviews.llvm.org/D147581
Currently the GPU build requires the `LLVM_LIBC_FULL_BUILD` option to be
set. This patch changes the logic so that it is always enabled when
targeting the GPU. Also, this patch allows `LIBC_GPU_BUILD` and
`LIBC_GPU_ARCHITECTURES` to both enable a GPU build. Now, enabling the
GPU support should only require the following CMake:
```
-DLLVM_ENABLE_RUNTIMES=libc -DLIBC_GPU_ARCHITECTURES=gfx1030
```
Reviewed By: jdoerfert, sivachandra
Differential Revision: https://reviews.llvm.org/D146979
With this change, libc-hdrgen is built like a host build tool like clang and used
to build libc for the target.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D141460
Currently, for BUILTIN_TARGETS and RUNTIME_TARGETS you can either use
the special "default" value, or a target triple.
For the "default" value, we don't set any target triple and passthrough
a subset of CMake variables into the subbuild. This is typically used
on Darwin where we build universal binaries and a single target triple
therefore isn't sufficient.
For the target triple value, you can set arbitrary CMake variables
through RUNTIMES_<target>_<variable>, but we always set target triple
to <target>. This gives more flexibility, because we can precisely
control what variables are set in the subbuild, but is unsuitable for
platforms like Darwin.
To address this, we would like to introduce a third option which is
similar to the second option, except we won't set target triple in
the subbuild (you can always do so yourself by setting the appropriate
CMake variable, e.g. RUNTIMES_<name>_CMAKE_C_COMPILER_TARGET=<triple>).
This change is a first step in that direction, by eliminating the support
of target triples from builtin_register_target and runtime_register_target
helper functions.
Differential Revision: https://reviews.llvm.org/D117263
LLVM_ENABLE_PER_TARGET_RUNTIME_DIR is set in llvm/CMakeLists.txt
and in llvm/runtimes/CMakeLists.txt.
This meant that anything you passed down, or any platform not using
this layout yet would have it enabled despite it being OFF earlier.
To fix this, check if we have already defined the variable
and if so, use that value.
bultin_register_target I don't fully understand the purpose of.
So for now I have left it setting the value to ON. The rest will
respect what was previously set.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D139536
It currently renamed to "llvmlibc" under the runtimes/boostrap build.
This prevents us from making a full libc build.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D142919
If LLVM_BUILTIN_TARGETS is not set, no OS specific variants will be
created, causing CMake build failure. Depend on the generic builtins
target if LLVM_BUILTIN_TARGETS is not set.
Differential Revision: https://reviews.llvm.org/D141273
We don't need to have built all the builtins before building the
runtimes for a particular target, only the builtins for that target.
While I'm here, rename the variable that stores the builtins dep to
something less generic than `deps`, to minimize the chances of
accidentally using a variable with the same name from an outer scope.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D139913
Summary:
We need to forward certain CMake definitions to the runtimes build when
using `-DLLVM_ENABLE_RUNTIMES=libc`. The `libc` project uses both
`LLVM_LIBC` and `LIBC` prefixes. Previously we only forwarded
`LLVM_LIBC`. This patch adds the `LIBC_` prefix, using the underscore to
separate it from `LIBCXX`.
This reverts commit bec8a372fc.
This causes many of these errors to appear when rebuilding runtimes part
of fuchsia's toolchain:
ld.lld: error:
/usr/local/google/home/paulkirth/llvm-upstream/build/lib/x86_64-unknown-linux-gnu/libunwind.a(libunwind.cpp.o)
is incompatible with elf64-x86-64
This can be reproduced by making a complete toolchain, saving any source
file with no changes, then rerunning ninja distribution.
The sub-component check targets won't be automatically created until the
runtime configurations have run (and the main LLVM configure has rerun
afterwards). Work around this by creating check- targets for components
in LLVM_RUNTIME_DISTRIBUTION_COMPONENTS as well (and making sure they
get the proper test dependencies).
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D138967
Right now, sub-components are only accounted for when the runtime has
been configured and the main LLVM configure is rerun after that. We can
make use of LLVM_RUNTIME_DISTRIBUTION_COMPONENTS to make sub-component
targets available from the start, but that currently clashes with the
sub-component target generation once they are picked up. Make sure we
don't create duplicate targets; an analogous check already exists in
runtime_default_target.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D138966
We were previously naming sub-component stripped install targets as
`install-${component}-stripped-${triple}`, whereas everywhere else names
them `install-${component}-${triple}-stripped`. This inconsistency would
cause issues when LLVM_RUNTIME_DISTRIBUTION_COMPONENTS contained a
sub-component (which I'm addding support for next).
Reviewed By: phosek, #libc, #libc_abi, ldionne
Differential Revision: https://reviews.llvm.org/D138965
This variable is derived from LLVM_DEFAULT_TARGET_TRIPLE by default,
but using a separate variable allows additional normalization to be
performed if needed.
Differential Revision: https://reviews.llvm.org/D137451
The `LLVM_ENABLE_RUNTIMES' mode is commonly used to build runtimes that
depend on an up-to-date version of clang. Currently, `libc` uses some
internal variables that are not forwarded when building in this mode.
This patch forwards the relevent arguments beginning with `LLVM_LIBC` to
the build when built this way.
Reviewed By: tianshilei1992
Differential Revision: https://reviews.llvm.org/D137977
We don't know which test suites are going to be included by runtimes
builds so we cannot include those before running the sub-build, but
that's not possible during the LLVM build configuration. We instead use
a response file that's populated by the runtimes build as a level of
indirection.
This addresses the issue described in:
https://discourse.llvm.org/t/cmake-regeneration-is-broken/62788
Differential Revision: https://reviews.llvm.org/D132438
This will make the following patches to migrate projects off of the
LLVM_ENABLE_PROJECTS build onto the LLVM_ENABLE_RUNTIMES build much
easier to comprehend. This patch should be a NFC since it keeps the
same set of runtimes being built by default.
Differential Revision: https://reviews.llvm.org/D132478
We don't know which test suites are going to be included by runtimes
builds so we cannot include those before running the sub-build, but
that's not possible during the LLVM build configuration. We instead use
a response file that's populated by the runtimes build as a level of
indirection.
This addresses the issue described in:
https://discourse.llvm.org/t/cmake-regeneration-is-broken/62788
Differential Revision: https://reviews.llvm.org/D132438
As reported in [1], cxx-headers is not a valid distribution target
because it is an interface target in CMake. This breaks the most
basic MultiDistributionExample of the runtimes build.
This patch handles interface targets by getting rid of the assumption
that all distribution components have a target associated to them. It
is valid for a distribution component to only have a `install-FOO`
target.
In the case where only `cxx-headers` is provided as a distribution
component, `ninja toolchain-distribution` will not build anything
after this patch, since there is effectively nothing to build for
the `cxx-headers` target. However, running `ninja install-toolchain-distribution`
will build everything, as expected.
[1]: https://discord.com/channels/636084430946959380/636732894974312448/1010013287464828968
Differential Revision: https://reviews.llvm.org/D132387
This is motivated by https://reviews.llvm.org/D115852#3226050 where passing
`LLVM_USE_LINKER` in PASSTHROUGH_PREFIXES breaks cross-compilation
(e.g. targeting Windows on a Linux host). As suggested on that diff, implement
an override for it by allowing users to pass `RUNTIMES_${target}_LLVM_USE_LINKER`
to specify the linker for runtimes. Defaults to host linker if not specified.
Reviewed By: phosek, smeenai
Differential Revision: https://reviews.llvm.org/D131051
This reverts commit ec10ac750a.
See https://discourse.llvm.org/t/cmake-regeneration-is-broken/62788.
This change caused Ninja's CMake regeneration to depend on the build,
which prevented CMake regeneration from functioning properly and caused
spurious build failures on incremental builds when a CMake change
occurred.
This partially reverts commit 9cddfe3085,
specifically passthrough for CMAKE_OSX_* since this can lead to build
passing through internal variables when it's not intended.
The mechanism behind "check-all" is recording params of add_lit_testsuite()
calls in global variables LLVM_LIT_*, and then creating an extra suite with
their union at the end.
This avoids composing the check-* targets directly, which doesn't work well.
We generalize this by allowing multiple families of variables LLVM_{name}_LIT_*:
umbrella_lit_testsuite_begin(check-foo)
... test suites here will be added to LLVM_FOO_LIT_* variables ...
umbrella_lit_testsuite_end(check-foo)
(This also moves some implementation muck out of {llvm,clang}/CMakeLists.txt
This patch also changes check-clang-tools to use be an umbrella test target,
which means the clangd and clang-pseudo tests are included in it, along with the
the other testsuites that already are (like check-clang-extra-clang-tidy).
Differential Revision: https://reviews.llvm.org/D121838
