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.
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.
When cross-compiling a Windows clang with `-DLLVM_BUILD_INSTRUMENTED`,
the profiling compiler-rt is linked to binaries, as one would expect,
but the profiling compiler-rt contains objects with `/DEFAULTLIB:LIBCMT`
and `/DEFAULTLIB:OLDNAMES` directives, which makes the build expect
`LIBCMT.lib` and `OLDNAMES.lib`, but they are nowhere to be found
because they are in lowercase. While the WinMsvc.cmake helper recreates
symbolic links to work around such case sensitivity issues for the
Windows SDK libs, it doesn't do so for the MSVC libs, which we add here.
ConstantFolding behaves differently depending on host's `HAS_IEE754_FLOAT128`.
LLVM should not change the behavior depending on host configurations.
This reverts commit 14c7e4a1844904f3db9b2dc93b722925a8c66b27.
(llvmorg-20-init-3262-g14c7e4a18449 and llvmorg-20-init-3498-g001e423ac626)
The intent is that the tests should not be running on PowerPC as the fp128 type
will differ. This attempts to fix the bots by using __powerpc__ instead, which
appears to be defined in godbolt.
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
This is a reland of (#96287). This patch attempts to reduce the reverted
patch's clang compile time by removing #includes of float128.h and
inlining convertToQuad functions instead.
This is a reland of #96287. This change makes tests in logf128.ll ignore
the sign of NaNs for negative value tests and moves an #include <cmath>
to be blocked behind #ifndef _GLIBCXX_MATH_H.
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.
