This reverts commit 785e7f06ddb1ba36aa679d23436726dcf61f8afb.
It did not solve the problem with flang-aarch64-libcxx and caused
another failure with openmp-offload-amdgpu-runtime-2.
The buidbot
[flang-aarch64-libcxx](https://lab.llvm.org/buildbot/#/builders/89) is
currently failing with an ABI issue. The suspected reason is that
LLVMSupport.a is built using libc++, but the unittests are using the
default C++ standard library, libstdc++ in this case. This predefined
`llvm_gtest` target uses the LLVMSupport from `find_package(LLVM)`,
which finds the libc++-built LLVMSupport.
To fix, store the `LLVM_ENABLE_LIBCXX` setting in the LLVMConfig.cmake
such that everything that links to LLVM libraries use the same standard
library. In this case discussed in
https://github.com/llvm/llvm-zorg/pull/387 it was the flang-rt
unittests, but other runtimes with GTest unittests should have the same
issue (e.g. offload), and any external project that uses
`find_package(LLVM)`.
Reverts llvm/llvm-project#133265
This causes the whole libc++ CI to fail, since we're not building
against a compiler built from current trunk. Specifically, the CMake
changes causes some feature detection to fail, resulting in CMake
being unable to configure libc++.
This turns on the unnecessary-virtual-specifier warning in general, but
disables it when building LLVM. It also tweaks the warning description
to be slightly more accurate.
Background: I've been working on cleaning up this warning in two
codebases: LLVM and chromium (plus its dependencies). The chromium
cleanup has been straightforward. Git archaeology shows that there are
two reasons for the warnings: classes to which `final` was added after
they were initially committed, and classes with virtual destructors that
nobody remarks on. Presumably the latter case is because people are just
very used to destructors being virtual.
The LLVM cleanup was more surprising: I discovered that we have an [old
policy](https://llvm.org/docs/CodingStandards.html#provide-a-virtual-method-anchor-for-classes-in-headers)
about including out-of-line virtual functions in every class with a
vtable, even `final` ones. This means our codebase has many virtual
"anchor" functions which do nothing except control where the vtable is
emitted, and which trigger the warning. I looked into alternatives to
satisfy the policy, such as using destructors instead of introducing a
new function, but it wasn't clear if they had larger implications.
Overall, it seems like the warning is genuinely useful in most codebases
(evidenced by chromium and its dependencies), and LLVM is an unusual
case. Therefore we should enable the warning by default, and turn it off
only for LLVM builds.
We're seeing following configuration error when building the `runtimes`
target on our buildbots:
```
CMake Error at /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-sanitized/llvm-project/llvm/cmake/modules/CheckProblematicConfigurations.cmake:14 (if):
if given arguments:
"STREQUAL" "MSVC"
Unknown arguments specified
Call Stack (most recent call first):
/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-sanitized/llvm-project/llvm/cmake/modules/HandleLLVMOptions.cmake:10 (include)
CMakeLists.txt:175 (include)
```
If I understand correctly this happens because ${CMAKE_CXX_COMPILER_ID}
is empty. Quoting it should make the comparison work for those cases.
Move `FindLibcCommonUtils` from LLVM's CMake module directory to the
shared top-level CMake directory, as the module is intended to be used
from within the source tree rather than the installed LLVM version. This
fixes standalone offload builds after #131205.
Key Instructions will start development behind a compile time flag to avoid
passing on the increased memory usage to all debug builds. We're working on
improving DILocation memory characteristics simultaneously; once that work lands
we can remove `EXPERIMENTAL_KEY_INSTRUCTIONS`.
This patch doesn't add any code, it's just so we can get the SIE buildbot
building with the new option right away.
Summary:
Always passing this option is problematic since it is not supported by
`clang.` this leads to conflicts when using extra CMake tools like
`compile-commands` or `include-what-you-use`. This mainly works around a
bug that showed up during the LTO build. Theoretically this can show up
without LTO, but it's likely to work.
This can be removed once
https://github.com/llvm/llvm-project/issues/24952 is resolved.
Summary:
This patch moves the RPC server handling to be a header only utility
stored in the `shared/` directory. This is intended to be shared within
LLVM for the loaders and `offload/` handling.
Generally, this makes it easier to share code without weird
cross-project binaries being plucked out of the build system. It also
allows us to soon move the loader interface out of the `libc` project so
that we don't need to bootstrap those and can build them in LLVM.
Details:
- Previously, we used the LLVM_BUILD_TELEMETRY flag to control whether
any Telemetry code will be built. This has proven to cause more nuisance
to both users of the Telemetry and any further extension of it. (Eg., we
needed to put #ifdef around caller/user code)
- So the new approach is to:
+ Remove this flag and introduce LLVM_ENABLE_TELEMETRY which would be
true by default.
+ If LLVM_ENABLE_TELEMETRY is set to FALSE (at buildtime), the library
would still be built BUT Telemetry cannot be enabled. And no data can be
collected.
The benefit of this is that it simplifies user (and extension) code
since we just need to put the check on Config::EnableTelemetry. Besides,
the Telemetry library itself is very small, hence the additional code to
be built would not cause any difference in build performance.
---------
Co-authored-by: Pavel Labath <pavel@labath.sk>
Extract Flang's runtime library to use the LLVM_ENABLE_RUNTIME
mechanism. It will only become active when
`LLVM_ENABLE_RUNTIMES=flang-rt` is used, which also changes the
`FLANG_INCLUDE_RUNTIME` to `OFF` so the old runtime build rules do not
conflict. This also means that unless `LLVM_ENABLE_RUNTIMES=flang-rt` is
passed, nothing changes with the current build process.
Motivation:
* Consistency with LLVM's other runtime libraries (compiler-rt, libc,
libcxx, openmp offload, ...)
* Allows compiling the runtime for multiple targets at once using the
LLVM_RUNTIME_TARGETS configuration options
* Installs the runtime into the compiler's per-target resource directory
so it can be automatically found even when cross-compiling
Also see RFC discussion at
https://discourse.llvm.org/t/rfc-use-llvm-enable-runtimes-for-flangs-runtime/80826
Prefers the page size to come from the AUX vector, `getpagesize` is
removed from POSIX.1-2001. Also throws in a couple asserts to ensure the
page size is a valid value.
Add `LLVM_BUILD_TELEMETRY` to the list of flags exposed in
`LLVMConfig.cmake`. This fixes telemetry library being misdetected as
`OFF` when building LLDB standalone.
Fixes bac62ee5b473e70981a6bd9759ec316315fca07d.
------
I guess this also needs a backport to 20.x.
* When building on Windows hosts, PDBs aren't installed to the
`CMAKE_INSTALL_PREFIX`.
* This PR addresses it solely for `llvm-*` executables.
* Similar changes are required in `AddClang.cmake`, `AddLLD.cmake`, etc.
I'd be happy to queue those PRs after this one.
If LLVM_TOOL_LLVM_DRIVER_BUILD is enabled, make sure
LLVM_TOOLCHAIN_TOOLS includes llvm-driver, otherwise with
LLVM_INSTALL_TOOLCHAIN_ONLY will install an invalid toolchain
Co-authored-by: Andarwinux <Andarwinux@users.noreply.github.com>
On systems with glibc, clock_gettime() was moved from librt to libc in
version 2.17, in which case the current librt detection attempt would
always fail.
Look for shm_open instead, like other parts of the tree also do when
looking for librt.
Co-authored-by: Raphael Kubo da Costa <kubo@igalia.com>
RFC:
https://discourse.llvm.org/t/rfc-cmake-linker-flags-need-wl-equivalent-for-intel-c-icx-on-windows/82446
The Intel C++ Compiler (ICX) passes linker flags through the driver
unlike MSVC and clang-cl, and therefore needs them to be prefixed with
`/Qoption,link` (the equivalent of `-Wl,` for gcc on *nix).
Previous PRs did not catch this because I did not try building with
`LLVM_BUILD_INSTRUMENTED=ON`.
`CMAKE_CXX_LINKER_WRAPPER_FLAG` is empty for plain clang-cl (icx on
windows behaves as clang-cl), so this is NFC for clang-cl.
If Polly is built with LLVM_POLLY_LINK_INTO_TOOLS=ON (the default for
monorepo builds), then Polly will become a dependency of the
LLVMExtensions component, which is part of LLVMExports. As such, all the
Polly libraries also have to be part of LLVMExports.
However, if Polly is built with LLVM_POLLY_LINK_INTO_TOOLS=OFF, we also
end up adding Polly libraries to LLVMExports. This is undesirable, as it
adds a hard dependency from llvm on polly.
Fix this by only exporting polly libraries from LLVMExports if
LLVM_POLLY_LINK_INTO_TOOLS is enabled.
This patch removes 11 `check_include_file` invocations from
configuration phase of LLVM subproject on most of the platforms,
hardcoding the results. Fallback is left for platforms that we don't
document as supported or that are not detectable via
`CMAKE_SYSTEM_NAME`, e.g. z/OS.
This patch reduces configuration time on Linux by 10%, going from 44.7
seconds down to 40.6 seconds on my Debian machine (ramdisk, `cmake
-DLLVM_ENABLE_PROJECTS="clang;lldb;clang-tools-extra"
-DLLVM_ENABLE_RUNTIMES="libunwind;libcxx;libcxxabi"
-DCMAKE_BUILD_TYPE=RelWithDebInfo -DLLVM_OPTIMIZED_TABLEGEN=ON
-DLLVM_TARGETS_TO_BUILD="X86" -DLLVM_ENABLE_DOXYGEN=ON
-DLLVM_ENABLE_LIBCXX=ON -DBUILD_SHARED_LIBS=ON -DLLDB_ENABLE_PYTHON=ON
~/endill/llvm-project/llvm`).
In order to determine the values to hardcode, I prepared the following
header:
```cpp
#include <dlfcn.h>
#include <errno.h>
#include <fcntl.h>
#include <fenv.h>
#include <mach/mach.h>
#include <malloc/malloc.h>
#include <pthread.h>
#include <signal.h>
#include <sys/ioctl.h>
#include <sys/mman.h>
#include <sys/param.h>
#include <sys/resource.h>
#include <sys/stat.h>
#include <sys/time.h>
#include <sys/types.h>
#include <sysexits.h>
#include <termios.h>
#include <unistd.h>
int main() {}
```
and tried to compile it on the oldest versions of platforms that are
still supported (which was problematic to determine sometimes): macOS
12, Cygwin, DragonFly BSD 6.4.0, FreeBSD 13.3, Haiku R1 beta 4, RHEL
8.10 as a glibc-based Linux, Alpine 3.17 as musl-based Linux, NetBSD 9,
OpenBSD 7.4, Solaris 11.4, Windows SDK 10.0.17763.0, which corresponds
to Windows 10 1809 and is the oldest Windows 10 SDK in Visual Studio
Installer.
For platforms I don't have access to, which are AIX 7.2 TL5 and z/OS
2.4.0, I had to rely on the official documentation. I suspect that AIX
offers a better set of headers than what this PR claims, so I'm open to
input from people who have access to a live system to test it.
Similarly to AIX, I have values for z/OS compiled from the official
documentation that are not included in this patch, because apparently
upstream CMake doesn't even support z/OS, so I don't even know how to
make a place to hold those values. I see `if (ZOS)` in several places
across our CMake files, but it's a mystery to me where this variable
comes from. Input from people who have access to live z/OS instance is
welcome.
The build system is fragile by allowing multiple invocation of
subprocess builds in the native folder for Make generator.
For example, during sub-invocation of the native llvm-config,
llvm-min-tblgen is also built. If there is another sub-invocation of the
native llvm-min-tblgen build running in parallel, they may overwrite
each other's build results, and may lead to errors like "Text file
busy".
This patch adds a cmake script that uses file lock to serialize all
native builds for Make generator.
These are unneeded even on AIX, PURE_WINDOWS, and ZOS (per #104706)
* HAVE_ERRNO_H: introduced by 1a93330ffa2ae2aa0b49461f05e6f0d51e8443f8 (2009) but unneeded.
The guarded ABI is unconditionally used by lldb.
* HAVE_FCNTL_H
* HAVE_FENV_H
* HAVE_SYS_STAT_H
Pull Request: https://github.com/llvm/llvm-project/pull/123087
Bolt makes use of add_llvm_library and as such ends up exporting its
libraries from LLVMExports.cmake, which is not correct.
Bolt doesn't have its own exports file, and I assume that there is no
desire to have one either -- Bolt libraries are not intended to be
consumed as a cmake module, right?
As such, this PR adds a NO_EXPORT option to simplify exclude these
libraries from the exports file.
Extend the special logic for finding `zstd.dll` in `Findzstd` to apply
to all MSVC-compatible configurations such as Clang targeting MSVC.
Fixes#121345
This tool is used for SPGO and is invoked directly by users as described
in the Clang User's Manual[^1].
This change will include llvm-profgen in installations configured with
LLVM_INSTALL_TOOLCHAIN_ONLY, such as those provided by LLVM's executable
Windows installers. This is useful now that LLVM can perform SPGO on
Windows.
[^1]:
https://clang.llvm.org/docs/UsersManual.html#using-sampling-profilers
llvm_add_tool() currently does not respect the passed project and puts
all tools into LLVMExports.cmake. This means that we end up with
binaries like mlir-opt in LLVMExports.cmake instead of
MLIRTargets.cmake, where they should be.
Adjust llvm_add_tool() to take the project into account.
We'd like to build runtimes using FatLTO (see
https://llvm.org/docs/FatLTO.html for details). This gives us more
control over how libc++ can be consumed by users of our toolchain, like
the Fuchsia SDK.
Further cleanups from old hdrgen removal. I didn't realize there were
cmake
variables related to old hdrgen spread out throughout more of the source
tree.
Link: #117220
Link: #117208
Summary:
We use the NATIVE directory for cross-compiling tools that need to be
run on the host. This was not forwarding the CMake arguments we used to
check if this was a GPU compile that created its own tools. Forward that
and simplify.
Fixes https://github.com/llvm/llvm-project/issues/118558
When configuring CMake with Clang in MSVC mode, Clang can either be
invoked with the MSVC style driver (clang-cl) or the GNU style driver
(clang). When using the MSVC style driver, CMake sets the CMake variable
MSVC (which indicates the kind of command line interface), but when
using the GNU style driver, this variable isn't set, while Clang still
operates in MSVC mode.
Even though CMake doesn't set the variable MSVC, it still does set
CMAKE_C_COMPILER_ARCHITECTURE_ID, which it does set for MSVC and Clang
in MSVC mode, but not for Clang in MinGW mode.
For this configuration, use the MSVC style,
CMAKE_C_COMPILER_ARCHITECTURE_ID based GetHostTriple implementation.
Fix a number of dependencies issue to build mlir-linalg-ods-yaml-gen
host binary which make a cross-build using the Make generator fail.
Namely:
- do not use binary path for the custom target created when
LLVM_USE_HOST_TOOLS is true;
- use target name instead of name of variable holding the target name
for add_custom_target and set_target_properties in setup_host_tool();
- force setting of executable and target cache variable which are only
used as global variables;
- remove dependency on target defined in different directory in
add_linalg_ods_yaml_gen() since add_custom_target DEPENDS can only be
used on "files and outputs of custom commands created with
add_custom_command() command calls in the same directory";
- remove unneeded dependency on ${MLIR_LINALG_ODS_YAML_GEN_EXE}, the
target dependency will ensure the binary will be built.
Note that we keep using ${MLIR_LINALG_ODS_YAML_GEN_EXE} in the COMMAND
rather than use ${MLIR_LINALG_ODS_YAML_GEN_TARGET} because when
LLVM_NATIVE_TOOL_DIR is used the latter is an empty string.
Testing-wise, all three codepaths in get_host_tool_path() were tested
with both GNU Make and Ninja generators:
- cross-compiling with LLVM_NATIVE_TOOL_DIR checks the if path;
- cross-compiling without LLVM_NATIVE_TOOL_DIR checks the elseif path;
- native build without LLVM_NATIVE_TOOL_DIR checks the else path.
When compiling LLVM with -std=c++ instead of -std=gnu we'd fail to detect many newer POSIX functions.
We define it for the whole of LLVM anyway so moving the definition to the top fixes detection of a bunch of these on such setups.
Keeping it at the top also avoids accidentally introducing new dependent checks before it being defined.
the -undefined suppress option for Apple's linker is deprecated and was
producing multiple warnings. This updates it to dynamic_lookup, which
has much the same effect, but avoids these deprecation warnings.
The Intel C++ Compiler (ICX) passes linker flags through the driver
unlike MSVC and clang-cl, and therefore needs them to be prefixed with
`/Qoption,link` (the equivalent of `-Wl,` for gcc on *nix).
Use `LINKER:` prefix wherever supported by cmake, when that's not
possible fall-back to `${CMAKE_CXX_LINKER_WRAPPER_FLAG}`. CMake replaces
these with `/Qoption,link` for ICX and with the empty string for MSVC
and clang-cl.
For `target_link_libraries` neither `LINKER:` (not supported prior to
CMake 3.32) nor `${CMAKE_CXX_LINKER_WRAPPER_FLAG}` (does not begin with
`-` would be taken as a library name) works, use `-Qoption,link`
directly within a conditional generator expression that we're linking
with ICX.
For MSVC and clang-cl no functional change is intended.
Tested by compiling with ICX and setting
`CMAKE_(EXE|SHARED|STATIC|MODULE)_LINKER_FLAGS_INIT` to
`-Werror=unknown-argument`.
RFC:
https://discourse.llvm.org/t/rfc-cmake-linker-flags-need-wl-equivalent-for-intel-c-icx-on-windows/82446
Fix a number of dependencies issue to build mlir-linalg-ods-yaml-gen
host binary which make a cross-build using the Make generator fail.
Namely:
- do not use binary path for the custom target created when
LLVM_USE_HOST_TOOLS is true;
- use target name instead of name of variable holding the target name
for add_custom_target and set_target_properties in setup_host_tool();
- remove dependency on target defined in different directory in
add_linalg_ods_yaml_gen() since add_custom_target DEPENDS can only be
used on "files and outputs of custom commands created with
add_custom_command() command calls in the same directory";
- remove unneeded dependency on ${MLIR_LINALG_ODS_YAML_GEN_EXE}, the
target dependency will ensure the binary will be built.
Note that we keep using ${MLIR_LINALG_ODS_YAML_GEN_EXE} in the COMMAND
rather than use ${MLIR_LINALG_ODS_YAML_GEN_TARGET} because when
LLVM_NATIVE_TOOL_DIR is used the latter is an empty string.
Testing-wise, all three codepaths in get_host_tool_path() were tested
with both GNU Make and Ninja generators:
- cross-compiling with LLVM_NATIVE_TOOL_DIR checks the if path;
- cross-compiling without LLVM_NATIVE_TOOL_DIR checks the elseif path;
- native build without LLVM_NATIVE_TOOL_DIR checks the else path.
