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
This patch removes llvm::is_trivially_copyable as it seems to be dead.
Once I remove it, HAVE_STD_IS_TRIVIALLY_COPYABLE has no users, so this
patch removes the macro also.
The comment on llvm::is_trivially_copyable mentions GCC 4.9, but note
that we now require GCC 7.1 or higher.
Differential Revision: https://reviews.llvm.org/D132328
We held off on this before as `LLVM_LIBDIR_SUFFIX` conflicted with it.
Now we return this.
`LLVM_LIBDIR_SUFFIX` is kept as a deprecated way to set
`CMAKE_INSTALL_LIBDIR`. The other `*_LIBDIR_SUFFIX` are just removed
entirely.
I imagine this is too potentially-breaking to make LLVM 15. That's fine.
I have a more minimal version of this in the disto (NixOS) patches for
LLVM 15 (like previous versions). This more expansive version I will
test harder after the release is cut.
Reviewed By: sebastian-ne, ldionne, #libc, #libc_abi
Differential Revision: https://reviews.llvm.org/D130586
`add_llvm_library()` would cause the proto target to be added in `LLVMExports.cmake` and could fail an external configuration
of compiler-rt with error "The following imported targets are referenced, but are missing: grpc++ protobuf::libprotobuf"
Differential Revision: https://reviews.llvm.org/D132033
This fixes some fallout from D131282. Currently, add_tablegen() will add the tablegen target to LLVM_EXPORTS and associates the install with LLVMExports. For non-standalone builds, this means that you end up with mlir-tblgen and clang-tblgen in LLVMExports.
However, these projects should instead be using MLIR_EXPORTS/MLIRTargets and CLANG_EXPORTS/ClangTargets. To fix this, add an extra EXPORT option and make use of get_target_export_arg() to create the correct export argument.
Reviewed By: ashay-github
Differential Revision: https://reviews.llvm.org/D131565
Warns on potentially unintended use of C++17 Class Template Argument
Deduction. Use of this feature with types that aren't intended to
support it may may future refactorings of those types more difficult -
so this warning fires whenever the feature is used with a type that may
not have intended to be used with CTAD (the warning uses the existence
of at least one explicit deduction guide to indicate that a type
intentionally supports CTAD - absent that, it's assumed to not be
intended to support CTAD & produces a warning).
This is disabled in libcxx because lots of the standard library is
assumed to provide ctad-usable APIs and the false positive suppression
in the diagnostic is based on system header classification which doesn't
apply in the libcxx build itself.
Differential Revision: https://reviews.llvm.org/D131727
add_clang_library is not available in components other than clang and
clang-tool-extras. Trying to use this module elsewhere will cause cmake
error. `add_clang_library` doesn't seem necessary for clangd's GRPC.
Change it to a more generic `add_llvm_library` so it is easier to build
other downstream projects with GRPC that doesn't depend on clang.
Reviewed By: akyrtzi
Differential Revision: https://reviews.llvm.org/D131593
Move the `LLVM_INSTALL_PACKAGE_DIR` declaration from llvm/cmake/modules
directory to the top-level llvm/CMakeLists.txt, in order to fix
the regression in `llvm-config --cmakedir` output for installed LLVM.
Since the tools directory is processed by CMake prior to
llvm/cmake/modules, the llvm-config executable ended up using
the variable prior to it being defined and incorrectly used an empty
path, resulting in e.g.:
$ llvm-config --cmakedir
/usr/lib/llvm/16/
With this patch, the path is defined (and therefore the default value
is being set) prior to adding the tools subdirectory and llvm-config
starts working correctly:
$ llvm-config --cmakedir
/usr/lib/llvm/16/lib64/cmake/llvm
This fixes a regression introduced by D130539. Thanks to Petr Polezhaev
for reporting the problem @ https://bugs.gentoo.org/865165
Differential Revision: https://reviews.llvm.org/D131878
Andreas Hollandt