Age | Commit message (Collapse) | Author | Files | Lines |
|
Update the folder titles for targets in the monorepository that have not
seen taken care of for some time. These are the folders that targets are
organized in Visual Studio and XCode
(`set_property(TARGET <target> PROPERTY FOLDER "<title>")`)
when using the respective CMake's IDE generator.
* Ensure that every target is in a folder
* Use a folder hierarchy with each LLVM subproject as a top-level folder
* Use consistent folder names between subprojects
* When using target-creating functions from AddLLVM.cmake, automatically
deduce the folder. This reduces the number of
`set_property`/`set_target_property`, but are still necessary when
`add_custom_target`, `add_executable`, `add_library`, etc. are used. A
LLVM_SUBPROJECT_TITLE definition is used for that in each subproject's
root CMakeLists.txt.
|
|
In a nutshell, this moves our libomptarget code to populate the offload
subproject.
With this commit, users need to enable the new LLVM/Offload subproject
as a runtime in their cmake configuration.
No further changes are expected for downstream code.
Tests and other components still depend on OpenMP and have also not been
renamed. The results below are for a build in which OpenMP and Offload
are enabled runtimes. In addition to the pure `git mv`, we needed to
adjust some CMake files. Nothing is intended to change semantics.
```
ninja check-offload
```
Works with the X86 and AMDGPU offload tests
```
ninja check-openmp
```
Still works but doesn't build offload tests anymore.
```
ls install/lib
```
Shows all expected libraries, incl.
- `libomptarget.devicertl.a`
- `libomptarget-nvptx-sm_90.bc`
- `libomptarget.rtl.amdgpu.so` -> `libomptarget.rtl.amdgpu.so.18git`
- `libomptarget.so` -> `libomptarget.so.18git`
Fixes: https://github.com/llvm/llvm-project/issues/75124
---------
Co-authored-by: Saiyedul Islam <Saiyedul.Islam@amd.com>
|
|
This allows sharing the LLVM version number in libc++.
|
|
Summary:
I've begun treating GPU runtimes builds as cross-compiling with the LLVM
infrastructure. However, we include a lot of random stuff that the GPU
build isn't prepared to handle. This currently emits a warning, and
while it's not striclty necessary, is annoying. This patch suppresses it
by not including the standard GNU install directory resources when used
from the GPU.
|
|
Co-authored-by: Martin Storsjö <martin@martin.st>
|
|
This allows the parent build to depend on this target unconditionally
even when the tests are disabled.
|
|
This appears to have caused a variety of breakages, see comments on the PR.
> Summary:
> There are a few default options that LLVM adds that can be problematic
> for runtimes builds. These options are generally intended to handle
> building LLVM itself, but are also added when building in a runtimes
> mode. One such issue I've run into is that in `libc` we deliberately use
> `--target` to use a different device toolchain, which doesn't support
> some linker arguments passed via `-Wl`. This is observed in
> https://github.com/llvm/llvm-project/pull/73030 when attempting to use
> these options.
>
> This patch completely removes these default arguments.
>
> The consensus is that any issues created by this patch should ultimately
> be solved on a per-runtime basis.
This reverts commit ee922e6ebfb6aab722f6b0f7cfc0c20af636a250.
|
|
Summary:
There are a few default options that LLVM adds that can be problematic
for runtimes builds. These options are generally intended to handle
building LLVM itself, but are also added when building in a runtimes
mode. One such issue I've run into is that in `libc` we deliberately use
`--target` to use a different device toolchain, which doesn't support
some linker arguments passed via `-Wl`. This is observed in
https://github.com/llvm/llvm-project/pull/73030 when attempting to use
these options.
This patch completely removes these default arguments.
The consensus is that any issues created by this patch should ultimately
be solved on a per-runtime basis.
|
|
This reverts commit 79b03306af5c11d354fa90db8bfd7818cd811ef5.
I am seeing very confusing errors with the `libomptarget` test suite
when using dlopen / other flags. Reverting to investigate why this is.
|
|
Summary:
There are a few default options that LLVM adds that can be problematic
for runtimes builds. These options are generally intended to handle
building LLVM itself, but are also added when building in a runtimes
mode. One such issue I've run into is that in `libc` we deliberately use
`--target` to use a different device toolchain, which doesn't support
some linker arguments passed via `-Wl`. This is observed in
https://github.com/llvm/llvm-project/pull/73030 when attempting to use
these options.
This patch completely removes these default arguments.
The consensus is that any issues created by this patch should ultimately
be solved on a per-runtime basis.
|
|
runtime LLVM integration"
This reverts commit 6403287eff71a3d6f6c862346d6ed3f0f000eb70.
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.
|
|
LLVM integration
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
|
|
There are some issues in `llvm-libgcc` before this patch:
Commit c5a20b518203613497fa864867fc232648006068 ([llvm-libgcc] initial
commit)
uses `$<TARGET_OBJECTS:unwind_static>` to get libunwind objects, which
is empty.
The built library is actually a shared version of libclang_rt.builtins.
When configuring with `llvm/CMakeLists.txt`, target `llvm-libgcc`
requires a
corresponding target in `llvm-libgcc/CMakeLists.txt`.
Per target installation is not handled by `llvm-libgcc`, which is not
consistent
with `libunwind`.
This patch fixes those issues by:
Reusing target `unwind_shared` in `libunwind`, linking
`compiler-rt.builtins`
objects into it, and applying version script.
Adding target `llvm-libgcc`, creating symlinks, and utilizing cmake's
dependency
and component mechanism to ensure link targets will be built and
installed along
with symlinks.
Mimicking `libunwind` to handle per target installation.
It is quite hard to set necessary options without further modifying the
order of
runtime projects in `runtimes/CMakeLists.txt`. So though this patch
reveals the
possibility of co-existence of `llvm-libgcc` and
`compiler-rt`/`libunwind` in
`LLVM_ENABLE_RUNTIMES`, we still inhibit it to minimize influence on
other
projects, considering that `llvm-libgcc` is only intended for toolchain
vendors,
and not for casual use.
|
|
This module is only used in two places and its logic can be inlined and
simplified.
|
|
This reverts commit d763c6e5e2d0a6b34097aa7dabca31e9aff9b0b6.
Adds the patch by @hans from
https://github.com/llvm/llvm-project/issues/62719
This patch fixes the Windows build.
d763c6e5e2d0a6b34097aa7dabca31e9aff9b0b6 reverted the reviews
D144509 [CMake] Bumps minimum version to 3.20.0.
This partly undoes D137724.
This change has been discussed on discourse
https://discourse.llvm.org/t/rfc-upgrading-llvms-minimum-required-cmake-version/66193
Note this does not remove work-arounds for older CMake versions, that
will be done in followup patches.
D150532 [OpenMP] Compile assembly files as ASM, not C
Since CMake 3.20, CMake explicitly passes "-x c" (or equivalent)
when compiling a file which has been set as having the language
C. This behaviour change only takes place if "cmake_minimum_required"
is set to 3.20 or newer, or if the policy CMP0119 is set to new.
Attempting to compile assembly files with "-x c" fails, however
this is workarounded in many cases, as OpenMP overrides this with
"-x assembler-with-cpp", however this is only added for non-Windows
targets.
Thus, after increasing cmake_minimum_required to 3.20, this breaks
compiling the GNU assembly for Windows targets; the GNU assembly is
used for ARM and AArch64 Windows targets when building with Clang.
This patch unbreaks that.
D150688 [cmake] Set CMP0091 to fix Windows builds after the cmake_minimum_required bump
The build uses other mechanism to select the runtime.
Fixes #62719
Reviewed By: #libc, Mordante
Differential Revision: https://reviews.llvm.org/D151344
|
|
This reverts commit 65429b9af6a2c99d340ab2dcddd41dab201f399c.
Broke several projects, see https://reviews.llvm.org/D144509#4347562 onwards.
Also reverts follow-up commit "[OpenMP] Compile assembly files as ASM, not C"
This reverts commit 4072c8aee4c89c4457f4f30d01dc9bb4dfa52559.
Also reverts fix attempt "[cmake] Set CMP0091 to fix Windows builds after the cmake_minimum_required bump"
This reverts commit 7d47dac5f828efd1d378ba44a97559114f00fb64.
|
|
The owner of the last two failing buildbots updated CMake.
This reverts commit e8e8707b4aa6e4cc04c0cffb2de01d2de71165fc.
|
|
Unfortunatly not all buildbots are updated.
This reverts commit ffb807ab5375b3f78df198dc5d4302b3b552242f.
|
|
All build bots should be updated now.
This reverts commit 44d38022ab29a3156349602733b3459df5beef93.
|
|
This reverts commit 1ef4c3c859728008cf707cad8d67f45ae5070ae1.
Two buildbots still haven't been updated.
|
|
This reverts commit 92523a35a827539db8557bbc3ecab7f9ea3f6ade.
Reland to see whether CIs are updated.
|
|
llvm_check_compiler_linker_flag"
This reverts commit 55e65ad876e3ac0b1cb0410a5cce3554c009af65.
|
|
This isn't needed anymore.
Differential Revision: https://reviews.llvm.org/D144440
|
|
These will be replaced by CMake's check_linker_flag once we update
the minimum CMake version 3.20.
Differential Revision: https://reviews.llvm.org/D145716
|
|
This reverts commit a72165e5df59032cdd54dcb18155f2630d73abd1.
Some buildbots have not been updated yet.
|
|
This reverts commit 92523a35a827539db8557bbc3ecab7f9ea3f6ade.
Test whether all CI runners are updated.
|
|
Some build bots have not been updated to the new minimal CMake version.
Reverting for now and ping the buildbot owners.
This reverts commit 44c6b905f8527635e49bb3ea97dea315f92d38ec.
|
|
This partly undoes D137724.
This change has been discussed on discourse
https://discourse.llvm.org/t/rfc-upgrading-llvms-minimum-required-cmake-version/66193
Note this does not remove work-arounds for older CMake versions, that
will be done in followup patches.
Reviewed By: mehdi_amini, MaskRay, ChuanqiXu, to268, thieta, tschuett, phosek, #libunwind, #libc_vendors, #libc, #libc_abi, sivachandra, philnik, zibi
Differential Revision: https://reviews.llvm.org/D144509
|
|
llvm_check_compiler_linker_flag"
This reverts commit efae3174f09560353fb0f3d528bcbffe060d5438 since
it broke the standalone Flang build.
|
|
These have the same purposes but two different implementations.
llvm_check_compiler_linker_flag uses CMAKE_REQUIRED_FLAGS which affects
flags used both for compilation and linking which is problematic because
some flags may be link-only and trigger unused argument warning when set
during compilation. llvm_check_linker_flag does not have this issue so
we chose it as the prevailaing implementation.
Differential Revision: https://reviews.llvm.org/D143052
|
|
LLVM_DEFAULT_TARGET_TRIPLE
After D137870, LLVM_TARGET_TRIPLE is no longer defined on the runtime
path into compiler-rt. This patch creates a common block of code to set
LLVM_TARGET_TRIPLE equal to the default for both the llvm- and runtime-
paths.
Differential Revision: https://reviews.llvm.org/D138864
|
|
This is a preparation to require CMake 3.20.0 after LLVM 16 has been
released.
This change has been discussed on discourse
https://discourse.llvm.org/t/rfc-upgrading-llvms-minimum-required-cmake-version/66193
Reviewed By: #libc_vendors, MaskRay, ChuanqiXu, to268, thieta, stellaraccident, ldionne, #libc, #libc_abi, phosek
Differential Revision: https://reviews.llvm.org/D137724
|
|
This reverts commit bec8a372fc0db95852748691c0f4933044026b25.
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 dependency list is stored in a global property, so we need to fetch
it to a variable before using that variable. We also need to add the
list contents as dependencies correctly.
|
|
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
|
|
LLVM runtimes build already loads the LLVM config and sets all
appropriate variables, no need to do it again.
Differential Revision: https://reviews.llvm.org/D137870
|
|
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 reverts commit 992e10a3fce41255e4b11782f51d0f4b26dca14d.
Breaks builds with LLVM_INCLUDE_TESTS=OFF, see comments in D132438.
|
|
LLVM_ENABLE_RUNTIMES
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
|
|
Done according to @phosek's comments in D117537, but not done then to
separate pure refactor (that) from possible behavior change (this).
Wasn't working before, but I think that was due to an issue of mismatched variable names fixed in D110005.
Reviewed By: phosek, #libunwind, #libc_abi
Differential Revision: https://reviews.llvm.org/D117833
|
|
Reviewed By: ldionne, #libc, #libc_abi
Spies: h-vetinari, sstefan1, libcxx-commits, mgorny
Differential Revision: https://reviews.llvm.org/D129452
|
|
llvm-libgcc is not a part of `LLVM_ALL_RUNTIMES` because llvm-libgcc is
incompatible with an explicit libunwind and compiler-rt. This meant that
it was being filtered out and not built.
Differential Revision: https://reviews.llvm.org/D128568
|
|
LLVM_INCLUDE_TESTS is ON
7cc8377f removed the 'runtimes-test-depends' target in runtimes builds that
is assumed to exist when using a bootstrapped runtime build.
For a full analysis, see:
https://discourse.llvm.org/t/looking-for-guidance-on-broken-downstream-bootstrapped-runtimes-builds/62934
Differential Revision: https://reviews.llvm.org/D127325
|
|
This is the idiomatic way to handle include directories in CMake.
Differential Revision: https://reviews.llvm.org/D122614
|
|
This way, we could use it for LLVM_ENABLE_PROJECTS too if desired.
Differential Revision: https://reviews.llvm.org/D125121
|
|
toolchains
When we add `--unwindlib=none` during the CMake configure phase (to
make CMake linking tests succeed before the unwind library has been
built for the first time - when bootstrapping a cross toolchain from
scratch), we add it to `CMAKE_REQUIRED_FLAGS` to make later CMake tests
pass.
When the option is added to `CMAKE_REQUIRED_FLAGS`, it gets added to
both compilation and linking commands. When --unwindlib=none is added
to the compilation command, it causes warnings (about being unused
during compilation, as it only affects linking).
When all CMake test compilations produce warnings, later CMake tests
for `-Werror` fail.
Add `--{start,end}-no-unused-arguments` around `--unwindlib=none`, if
supported, to avoid unnecessary warnings due to this option.
If the CMake requirement is bumped to 3.14, we could use
`CMAKE_REQUIRED_LINK_OPTIONS` instead, removing the need for the
`--{start,end}-no-unused-arguments` options. (However, do note that
`CMAKE_REQUIRED_LINK_OPTIONS` is problematic in combination with
`CMAKE_TRY_COMPILE_TARGET_TYPE` set to `STATIC_LIBRARY`; see
https://gitlab.kitware.com/cmake/cmake/-/issues/23454.)
Differential Revision: https://reviews.llvm.org/D124377
|
|
This reverts commit 203455c85ad03325ce2d77f067f6ac953f2a32ce since
it breaks the OpenMP builders for AMDGPU.
|
|
This is the idiomatic way to handle include directories in CMake.
Differential Revision: https://reviews.llvm.org/D122614
|