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
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>
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.
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.
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.
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.
This reverts commit d6827f68ad9110ae0c9992de7b2e2eec0f23be14 due to the
following CMake configure failure being observed by some:
add_custom_target called with invalid target name
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.
This is part of a series of patches that tries to improve DILocation bug
detection in Debugify. This first patch adds the necessary CMake flag to
LLVM and a variable defined by that flag to LLVM's config header, allowing
the next patch to track information without affecting normal builds.
This series of patches adds a "DebugLoc coverage tracking" feature, that
inserts conditionally-compiled tracking information into DebugLocs (and
by extension, to Instructions), which is used by Debugify to provide
more accurate and detailed coverage reports. When enabled, this features
tracks whether and why we have intentionally dropped a DebugLoc,
allowing Debugify to ignore false positives. An optional additional
feature allows also storing a stack trace of the point where a DebugLoc
was unintentionally dropped/not generated, which is used to make fixing
detected errors significantly easier. The goal of these features is to
provide useful tools for developers to fix existing DebugLoc errors and
allow reliable detection of regressions by either manual inspection or
an automated script.
Only MSVC recognizes this flag, so be explicit. As an example the Intel
C++ Compiler (IntelLLVM in CMake) also has an MSVC compatible CLI, but
does not suppport this flag.
WinMsvc.cmake, used for cross-compiling LLVM, targetting Windows, puts
-libpath flags on the linker command line for the MSVC directories.
Those may contain clang runtime libraries that come from MSVC, and may
be incompatible with the clang compiler in use when it doesn't come from
MSVC (which is obviously the case on cross-compiles). By prioritizing
the clang runtime directory on the linker command line, we avoid those
libraries being picked up by the linker.
Try to detect if the git remote URL has a password or a Github token and
return an error teaching the user how to avoid leaking their password or
token.
These packaged are imported by LLVMConfig.cmake and so we should be
passing through the necessary variables from the parent build into the
subbuilds.
We use `CMAKE_CACHE_DEFAULT_ARGS` so subbuilds can override these
variables if needed.
These are my initial build and code changes to supporting building llvm
as shared library/DLL on windows(without force exporting all symbols)
and making symbol visibility hidden by default on Linux which adding
explicit symbol visibility macros to the whole llvm codebase.
Updated cmake code to allow building llvm-shlib on windows by appending
/WHOLEARCHIVE:lib to the linker options.
Remove the hardcoded CMake error from using LLVM_BUILD_LLVM_DYLIB on
windows.
Updated CMake to define new macros to control conditional export macros
in llvm/Support/Compiler.h
Use /Zc:dllexportInlines- when compiling with clang-cl on windows with a
opt out CMake option to disable using it.
Replace some use of LLVM_EXTERNAL_VISIBILITY with new export macros.
Some of the cmake and code changes are based on @tstellar's earlier PR
https://github.com/llvm/llvm-project/pull/67502.
I have Windows building using clang-cl, while for MSVC its at-least able
to build libllvm, but some tests can't build because llvm iterator
template metaprogramming that doesn't work well with dllexport. Linux
should build without issue. My full branch is here
https://github.com/fsfod/llvm-project/tree/llvm-export-api-20.0 and
including all the auto generated export macros from clang tooling based
system.
This fixes an odd problem with the regex when `CMAKE_INSTALL_LIBDIR` is
not defined:
`string sub-command REGEX, mode REPLACE: regex "$" matched an empty
string.`
Fixesllvm/llvm-project#83802
Exporting symbols from tools directory never worked with
`LLVM_EXPORT_SYMBOLS_FOR_PLUGINS=On`. When that options is on, only
symbols from the static library is linked is exported due to the export
symbols computation script. DynamicLibraryTests needs to export a symbol
from the tools/executable directory, so update it to use export list
instead.
Due to an issue mentioned in `llvm/projects/CMakeLists.txt`, libc build
is disabled by default when building with `clang-cl` on Windows. This PR
sets `LLVM_FORCE_BUILD_RUNTIME` to `ON` to bypass this limit for libc
and make libc build with `clang-cl` on Windows.
Fix the builds with LLVM_TOOL_LLVM_DRIVER_BUILD enabled.
LLVM_ENABLE_EXPORTED_SYMBOLS_IN_EXECUTABLES is not completely
compatible with export_executable_symbols as the later will be ignored
if the previous is set to NO.
Fix the issue by passing if symbols need to be exported to
llvm_add_exectuable so the link flag can be determined directly
without calling export_executable_symbols_* later.
