Currently, setting -DLLVM_ENABLE_LLD=ON on windows also requires setting
-DCMAKE_LINKER=lld-link.exe. This is both misleading and redundant.
Fix this by trying to find llvm-link.exe when -DLLVM_ENABLE_LLD=ON is
set and CMAKE_LINKER is not, and aborting otherwise.
Differential Revision: https://reviews.llvm.org/D140534
We were copying it into the installed version of the directory,
but not into the one in the build directory. Because of that it
was not directly usable as a cmake module by subprojects that
also use the driver functionality.
This reverts commit ae3e228af7.
Seems that it may form a wrong command line for 32-bit Halide builds
`-D_FILE_OFFSET_BITS="64 -D_DEBUG -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DSTDC_CONSTANT_MACROS -DSTDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS"` according to
Using CMAKE_CFG_INTDIR in paths that are used in configure_file,
resulted in a folder that is literally called '${CONFIGURATION}'
for the multi-config ninja build.
I think this is a regression from a while ago. Fix this by replacing
CMAKE_CFG_INTDIR with '.'. We can only create one of the
LLVMConfig.cmake files as the consuming CMake project can only import a
single file. This creates LLVMConfig.cmake and others in the place where
they were previously and where they are for a single-config build.
Differential Revision: https://reviews.llvm.org/D139623
Pass -D_FILE_OFFSET_BITS=64 to compiler flags on 32bit glibc based
systems. This will make sure that 64bit versions of LFS functions are
used e.g. seek will behave same as lseek64. Also revert [1] partially
because this added a cmake test to detect lseek64 but then forgot to
pass the needed macro to actual compile, this test was incomplete too
since libc implementations like musl has 64bit off_t by default on 32bit
systems and does not bundle[2] -D_LARGEFILE64_SOURCE under -D_GNU_SOURCE
like glibc, which means the compile now fails on musl because the cmake
check passes but we do not have _LARGEFILE64_SOURCE defined. Using the
*64 function was transitional anyways so use -D_FILE_OFFSET_BITS=64
instead
[1] 8db7e5e4ee
[2] https://git.musl-libc.org/cgit/musl/commit/?id=25e6fee27f4a293728dd15b659170e7b9c7db9bc
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D139752
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
The presence of dladdr on Linux depends on whether or not _GNU_SOURCE is
set.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D139575
This reverts commit bec8a372fc.
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.
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
Fix Findzstd CMake to handle shared libraries on OpenBSD correctly.
This userland does not use shared library symlinks without SOVERSION,
so the result of find_library() does not ever end with
zstd_SHARED_LIBRARY_SUFFIX. To work around this, reverse the logic
to compare the result against zstd_STATIC_LIBRARY_SUFFIX and assume
shared library otherwise.
While at it, fix the conditions not to fall back to "result is static
library" path if it actually was recognized as a shared library but
zstd_shared target already existed.
Fixes#59056
Differential Revision: https://reviews.llvm.org/D138361
This reverts commit 59052468c3.
It looks like this patch breaks the build when compiler-rt is passed to
LLVM_ENABLE_PROJECTS instead of LLVM_ENABLE_RUNTIMES.
This will help improve the project's layering, so that sub-projects
that don't actually need any llvm code can still use googletest
without having to reference code in the llvm directory.
This will also make it easier to consolidate and simplify the standalone
build configurations.
Reviewed By: stellaraccident, lattner, probinson, phosek
Differential Revision: https://reviews.llvm.org/D131919
Fixes warnings (or errors, if someone injects -Werror in their build system,
which happens in fact with some folks vendoring LLVM too) with Clang 16:
```
+/var/tmp/portage.notmp/portage/sys-devel/llvm-15.0.4/work/llvm_build-abi_x86_64.amd64/CMakeFiles/CMakeTmp/src.c:3:9: warning: a function declaration without a prototype
is deprecated in all versions of C [-Wstrict-prototypes]
-/var/tmp/portage.notmp/portage/sys-devel/llvm-14.0.4/work/llvm_build-abi_x86_64.amd64/CMakeFiles/CMakeTmp/src.c:3:9: error: a function declaration without a prototype is
deprecated in all versions of C [-Werror,-Wstrict-prototypes]
int main() {return 0;}
^
void
```
Differential Revision: https://reviews.llvm.org/D137503
* Set LLVM_ATOMIC_LIB to keep track of when we need to link against libatomic.
* Add detection of mold linker which is required for this.
* Use --as-needed when linking against libatomic as a bonus. On some platforms,
libatomic may be required only sometimes.
Bug: https://bugs.gentoo.org/832675
Thanks-to: Arfrever Frehtes Taifersar Arahesis <Arfrever@Apache.Org>
Tested-by: erhard_f@mailbox.org <erhard_f@mailbox.org>
Differential Revision: https://reviews.llvm.org/D136280
This reverts commit 12d8e7c6ad.
The Windows MLIR buildbot started failing with:
C:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\um\winbase.h(9531): error C2220: the following warning is treated as an error
C:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\um\winbase.h(9531): warning C5105: macro expansion producing 'defined' has undefined behavior
C:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\um\winbase.h(9531): note: to simplify migration, consider the temporary use of /Wv:18 flag with the version of the compiler with which you used to build without warnings
Since we now only support Visual Studio 2019 16.7 and newer, we're able to use the /Zc:preprocessor flag that turns on the standards-conforming preprocessor. Among other things, it correctly expands __VA_ARGS__. This enables removal of some boilerplate in D135128.
Reviewed By: Bigcheese, thieta
Differential Revision: https://reviews.llvm.org/D135128
Set a dummy CMAKE_INSTALL_LIBDIR in order to silence the following CMake
warning when executing LLVMInstallSymlink.cmake script:
CMake Warning (dev) at /usr/share/cmake/Modules/GNUInstallDirs.cmake:243 (message):
Unable to determine default CMAKE_INSTALL_LIBDIR directory because no
target architecture is known. Please enable at least one language before
including GNUInstallDirs.
Call Stack (most recent call first):
/usr/lib/llvm/16/lib64/cmake/llvm/LLVMInstallSymlink.cmake:5 (include)
tools/lld/cmake_install.cmake:66 (include)
cmake_install.cmake:52 (include)
Differential Revision: https://reviews.llvm.org/D136573
Using a Python script instead of the various shell commands means that
it is now possible to cross compile LLVM for Linux on Windows.
Differential Revision: https://reviews.llvm.org/D136092
On Windows we don't create symlinks for the binaries (clang++, clang-cl)
since the support requires special setup (group policy settings and
you need to know exactly our distribution story). But if you know
about these things and have a controlled environment there is a lot
of storage to be saved, so let's add a manual opt-in for using symlinks
on Windows with LLVM_FORCE_CREATE_SYMLINKS=ON.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D135578
Improve the logic in FindZstd to support finding both shared and static
variants of the zstd library simultaneously. Otherwise, if the shared
library is installed, zstd::libzstd_static is not declared at all
and CMake fails if LLVM_USE_STATIC_ZSTD is used.
Differential Revision: https://reviews.llvm.org/D135457
This is another attempt at https://reviews.llvm.org/D110489.
When build IREE we run into cases where we don't have / need
LLVM_VERSION_* etc set. Compilation fails if it isn't an integer.
Reviewed By: stellaraccident
Differential Revision: https://reviews.llvm.org/D135650
This module is used to find the system zstd library. The imported
targets intentionally use the same name as the generate zstd config
CMake file so these can be used interchangeably.
Differential Revision: https://reviews.llvm.org/D134990
This reverts commit 849059861c.
This breaks running llvm tests:
llvm-lit: /home/npopov/repos/llvm-project/llvm/utils/lit/lit/TestingConfig.py:138: fatal: unable to parse config file '/home/npopov/repos/llvm-project/build/test/lit.site.cfg.py', traceback: Traceback (most recent call last):
File "/home/npopov/repos/llvm-project/llvm/utils/lit/lit/TestingConfig.py", line 127, in load_from_path
exec(compile(data, path, 'exec'), cfg_globals, None)
File "/home/npopov/repos/llvm-project/build/test/lit.site.cfg.py", line 48, in <module>
config.have_zstd = FALSE
NameError: name 'FALSE' is not defined
This module is used to find the system zstd library. The imported
targets intentionally use the same name as the generate zstd config
CMake file so these can be used interchangeably.
Differential Revision: https://reviews.llvm.org/D134990
`LLVM_DISTRIBUTION_COMPONENTS` now influences the llvm binary in the
normal cmake output directory when it is set. This allows for
distribution targets to only include tools they want in the llvm
binary. It must be done this way because only one target can be
associated with a specific output name.
Differential Revision: https://reviews.llvm.org/D131310
GetHostTriple is used by the runtimes build, so this cmake file
must be exported. Otherwise it is not possible to build runtimes
against a previously built LLVM.
Differential Revision: https://reviews.llvm.org/D134730
regexp for try_run path expects '0 or more' digits which is incorrect because it should be 'one or more', regexp for header parsing expects 'exactly one' digit which is incorrect with current Z3 version (4.11.2)
Reviewed By: mikhail.ramalho
Differential Revision: https://reviews.llvm.org/D134261
Prior to this patch, a Windows build of llvm-lto using clang failed with
the error: `LTO.def: unknown file type`. The reason for this failure is
that .DEF files are used by the linker not by the clang compiler. The
MSVC compiler+linker handles this transparently, but if we're using
clang (or gcc), then we need to tell the compiler to forward this flag
to the linker. This patch adds the necessary `-Wl` flag to fix the
problem.
Reviewed By: rnk, mstorsjo
Differential Revision: https://reviews.llvm.org/D134165
Discovered an issue working in StableHLO when attempting to build with `-Wall -Werror`:
https://github.com/openxla/stablehlo/pull/137
Currently, if `LLVM_USE_LLD` and `-DCMAKE_CXX_FLAGS="${CMAKE_CXX_FLAGS} -Wall -Werror"`
are both specified for build, the build will error with:
```
-- Performing Test CXX_SUPPORTS_CUSTOM_LINKER - Failed
CMake Error at /usr/local/google/home/gleasonk/Coding/llvm-build/lib/cmake/llvm/HandleLLVMOptions.cmake:309 (message):
Host compiler does not support '-fuse-ld=lld'
...
$ cat <build_dir>/CMakeFiles/CMakeError.log
...
clang: error: argument unused during compilation: '-fuse-ld=lld' [-Werror,-Wunused-command-line-argument]
```
It looks like other repos have hit this same issue:
- https://github.com/golang/go/issues/41527 (mentioned in comment)
- https://github.com/iree-org/iree/pull/7450
This can be reproduced in llvm-project with the following build command:
```
# Compile command taken from https://mlir.llvm.org/getting_started/
# and modified for use case
cmake -G Ninja ../llvm \
-DLLVM_ENABLE_PROJECTS=mlir \
-DLLVM_BUILD_EXAMPLES=ON \
-DLLVM_TARGETS_TO_BUILD="X86;NVPTX;AMDGPU" \
-DCMAKE_BUILD_TYPE=Release \
-DLLVM_ENABLE_ASSERTIONS=ON \
-DCMAKE_CXX_COMPILER=clang++ \
-DCMAKE_C_COMPILER=clang \
-DLLVM_ENABLE_LLD=ON \
-DCMAKE_CXX_FLAGS="${CMAKE_CXX_FLAGS} -Wall -Werror"
```
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D134206
A simple sed doing these substitutions:
- `${LLVM_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}\>` -> `${LLVM_LIBRARY_DIR}`
- `${LLVM_BINARY_DIR}/bin\>` -> `${LLVM_TOOLS_BINARY_DIR}`
where `\>` means "word boundary".
The only manual modifications were reverting changes in
- `runtimes/CMakeLists.txt`
because these were "entry points" where we wanted to tread carefully not not introduce a "loop" which would end with an undefined variable being expanded to nothing.
There are some `${LLVM_BINARY_DIR}/lib` without the `${LLVM_LIBDIR_SUFFIX}`, but these refer to the lib subdirectory of the source (`llvm/lib`). That `lib` is automatically appended to make the local `CMAKE_CURRENT_BINARY_DIR` value by `add_subdirectory`; since the directory name in the source tree is fixed without any suffix, the corresponding `CMAKE_CURRENT_BINARY_DIR` will also be. We therefore do not replace it but leave it as-is.
This picks up where D133828 left off, getting the occurrences with*out* `CMAKE_CFG_INTDIR`. But this is difficult to do correctly and so not done in the (retroactively) previous diff.
This hopefully increases readability overall, and also decreases the usages of `LLVM_LIBDIR_SUFFIX`, preparing us for D130586.
Reviewed By: sebastian-ne
Differential Revision: https://reviews.llvm.org/D132316
add LLVM_PREFER_STATIC_ZSTD (default TRUE) cmake config flag
(compression test seems to fail for shared zstd on windows, note that zstd multithread is by default disabled in the static build so it may be a hidden variable)
propagate variable zstd_DIR in LLVMConfig.cmake.in
fix llvm-config CMakeLists.txt behavior for absolute libs windows
get zstd lib name
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D132870
We do keep using the flag with Clang, which should keep catching
such issues in buildbots.
With GCC, the warning can cause lots of loud notes about the
warning logic getting disabled in large source files.
Differential Revision: https://reviews.llvm.org/D132914
When building LLVM with LLVM_BUILD_TOOLS as OFF, numerous tools such as llvm-ar or llvm-objcopy end up still being built. The reason for this is that the symlink targets are unconditionally included in a Build-all build, causing the tool they're symlinking to be built after all.
This patch changes that behaviour to be more intuitive by only including the symlink in a Build-all build if the target they're linking to is also included.
Differential Revision: https://reviews.llvm.org/D132883
TLite is a lightweight, statically linkable[1], model evaluator, supporting a
subset of what the full tensorflow library does, sufficient for the
types of scenarios we envision having. It is also faster.
We still use saved models as "source of truth" - 'release' mode's AOT
starts from a saved model; and the ML training side operates in terms of
saved models.
Using TFLite solves the following problems compared to using the full TF
C API:
- a compiler-friendly implementation for runtime-loadable (as opposed
to AOT-embedded) models: it's statically linked; it can be built via
cmake;
- solves an issue we had when building the compiler with both AOT and
full TF C API support, whereby, due to a packaging issue on the TF
side, we needed to have the pip package and the TF C API library at
the same version. We have no such constraints now.
The main liability is it supporting a subset of what the full TF
framework does. We do not expect that to cause an issue, but should that
be the case, we can always revert back to using the full framework
(after also figuring out a way to address the problems that motivated
the move to TFLite).
Details:
This change switches the development mode to TFLite. Models are still
expected to be placed in a directory - i.e. the parameters to clang
don't change; what changes is the directory content: we still need
an `output_spec.json` file; but instead of the saved_model protobuf and
the `variables` directory, we now just have one file, `model.tflite`.
The change includes a utility showing how to take a saved model and
convert it to TFLite, which it uses for testing.
The full TF implementation can still be built (not side-by-side). We
intend to remove it shortly, after patching downstream dependencies. The
build behavior, however, prioritizes TFLite - i.e. trying to enable both
full TF C API and TFLite will just pick TFLite.
[1] thanks to @petrhosek's changes to TFLite's cmake support and its deps!
A simple sed doing these substitutions:
- `${LLVM_BINARY_DIR}/(\$\{CMAKE_CFG_INTDIR}/)?lib(${LLVM_LIBDIR_SUFFIX})?\>` -> `${LLVM_LIBRARY_DIR}`
- `${LLVM_BINARY_DIR}/(\$\{CMAKE_CFG_INTDIR}/)?bin\>` -> `${LLVM_TOOLS_BINARY_DIR}`
where `\>` means "word boundary".
The only manual modifications were reverting changes in
- `compiler-rt/cmake/Modules/CompilerRTUtils.cmake
- `runtimes/CMakeLists.txt`
because these were "entry points" where we wanted to tread carefully not not introduce a "loop" which would end with an undefined variable being expanded to nothing.
This hopefully increases readability overall, and also decreases the usages of `LLVM_LIBDIR_SUFFIX`, preparing us for D130586.
Reviewed By: sebastian-ne
Differential Revision: https://reviews.llvm.org/D132316
As reported in [1], cxx-headers is not a valid distribution target
because it is an interface target in CMake. This breaks the most
basic MultiDistributionExample of the runtimes build.
This patch handles interface targets by getting rid of the assumption
that all distribution components have a target associated to them. It
is valid for a distribution component to only have a `install-FOO`
target.
In the case where only `cxx-headers` is provided as a distribution
component, `ninja toolchain-distribution` will not build anything
after this patch, since there is effectively nothing to build for
the `cxx-headers` target. However, running `ninja install-toolchain-distribution`
will build everything, as expected.
[1]: https://discord.com/channels/636084430946959380/636732894974312448/1010013287464828968
Differential Revision: https://reviews.llvm.org/D132387
