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.
`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.
CMake -GXcode would otherwise offer to create one scheme for each
target, which ends up being a lot. For now, limit the default to the
`check-*` LIT targets, plus `ALL_BUILD` and `install`.
For targets that aren't in the default list, we now have a configuration
variable to promote an extra list of targets into schemes, for example
`-DLLVM_XCODE_EXTRA_TARGET_SCHEMES="TargetParserTests;SupportTests"` to
add schemes for `TargetParserTests` and `SupportTests` respectively.
Summary:
The `compiler-rt` project wants `LLVM_CMAKE_DIR` but the
`llvm_ExternalProject_add` interface sets the `LLVM_CONFIG_PATH`. This
patch just makes the utility pass that as well.
When building compiler-rt with MSVC, CMAKE_INSTALL_LIBDIR and
CMAKE_INSTALL_BINDIR are empty.
This causes error in Findzstd.cmake like the following:
CMake Error at C:/llvm/cmake/modules/Findzstd.cmake:39 (string):
string sub-command REGEX, mode REPLACE: regex "$" matched an empty
string.
Do not do the REGEX when CMAKE_INSTALL_LIBDIR and CMAKE_INSTALL_BINDIR
are empty.
Similar issues were reported by others at
e7fc7540da
When doing a runtimes build with LTO using ld.bfd (or ld.gold), the
build starts failing with ninja 1.12, which added a new critical path
scheduler. The reason is that LLVMgold.so is not available yet at the
point where runtimes start being build, leading to configuration
failures in the nested cmake invocation.
Fix this by adding an explicit dependency on LLVMgold.so if it is
available. (It may not always be necessary, e.g. if the used linker is
lld, but it would be hard to detect when exactly it may or may not be
needed, so always adding the dependency is safer.)
It's useful to use toolchain files for configuring runtimes builds.
Setting `CMAKE_<LANG>_FLAGS` is however forceful and precludes initialization from the _INIT variant meant to be set by toolchains.
The toolchain file still needs to append instead of just setting and be idempotent (`include_guard()`), but this way at least a special toolchain to account for LLVM won't be required.
If built statically, `libedit` may have a private static library
dependency on a provider of the `terminfo` API (e.g., `ncurses`). This
means that multiple libraries would need to be provided as the value for
`LibEdit_LIBRARIES`, but the current implementation of `FindLibEdit`
precludes this. This PR allows a list to be passed to
`LibEdit_LIBRARIES`.
This reverts commit fe82a3da36196157c0caa1ef2505186782f750d1.
This broke LLDB on MacOS due to a missing symbol during linking.
The fix has been applied in c6c08eee37bada190bd1aa4593c88a5e2c8cdaac.
Original commit message:
The terminfo dependency introduces a significant nonhermeticity into the
build. It doesn't respect `--no-undefined-version` meaning that it's not
a dependency that can be built with Clang 17+. This forces maintainers
of source-based distributions to implement patches or ignore linker
errors.
Remove it to reduce the closure size and improve portability of
LLVM-based tools. Users can still use command line arguments to toggle
color support expliticly.
Fixes#75490Closes#53294#23355
A follow-up to #92953. This should fix unexpected performance gains when Clang is built with GCC, and fix downstream LTO crashes reported in 4feae05c6a (r142466703)
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.
The terminfo dependency introduces a significant nonhermeticity into the
build. It doesn't respect `--no-undefined-version` meaning that it's not
a dependency that can be built with Clang 17+. This forces maintainers
of source-based distributions to implement patches or ignore linker
errors.
Remove it to reduce the closure size and improve portability of
LLVM-based tools. Users can still use command line arguments to toggle
color support expliticly.
Fixes#75490Closes#53294#23355
