- add `FindZSTD.cmake`
- add zstd to `llvm::compression` namespace
- add a CMake option `LLVM_ENABLE_ZSTD` with behavior mirroring that of `LLVM_ENABLE_ZLIB`
- add tests for zstd to `llvm/unittests/Support/CompressionTest.cpp`
Reviewed By: leonardchan, MaskRay
Differential Revision: https://reviews.llvm.org/D128465
- add check before truncating (un)compressed data buffer if the buffer is already a perfect length, to avoid triggering truncate assertion in edge case.
- explictly coerce LLVM_ENABLE_ZLIB to a 0 or 1 value in OFF case, to match current ON, FORCE_ON behavior.
- fix code style nits in zlib tests
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D129698
Pointed out in Issue #56432: the current reference models may not be
quite friendly to open source projects. Their purpose is only
illustrative - the expectation is that projects would train their own.
To avoid unintentionally pulling such a model, made the URL cmake
setting require explicit user setting.
Differential Revision: https://reviews.llvm.org/D129342
Originally, the nested build was set up with the CMake command
`execute_process` which implicitly passes CC/CXX variables for
the configured compiler, which then was picked up by the nested
CMake. (This CMake behaviour, to implicitly pass such variables
is up for discussion and might change in the future; see
https://gitlab.kitware.com/cmake/cmake/-/issues/21378.)
How the nested cmake build is set up was changed in
aa7d6db5c8 / D40229 - the old behaviour
was brought along by manually passing
-DCMAKE_CXX_COMPILER=${CMAKE_CXX_COMPILER} to the nested cmake
configuration. This was then later made optional in
f5f0fffea5 / D40947. But still,
the default if the user doesn't pass
CROSS_TOOLCHAIN_FLAGS_${target_name} (e.g. CROSS_TOOLCHAIN_FLAGS_NATIVE)
is to pass in the surrounding build's compiler - which usually
doesn't work, and is quite non-obvious to figure out.
Just drop the default passing of the outer compiler, when cross
compiling. This should avoid surprising cases of using the cross
compiler for the native build for essentially all new users trying
to cross compile, until they've discovered CROSS_TOOLCHAIN_FLAGS_NATIVE.
Keep passing these when not cross compiling, e.g. if building with
optimized tablegen.
This was already suggested at the end in D40229, but apparently never
acted upon.
Differential Revision: https://reviews.llvm.org/D126313
* Switch `$GRPC_OPTS` references to `${GRPC_OPTS}`
* Use `target_include_directories()` to add include search paths only for the targets the depend on `gRPC`
* Also find and include the search path for `abseil` headers (`gRPC` headers include them)
* Only setup the gRPC related targets once, so that `include(FindGRPC)` can be called from multiple tools
Differential Revision: https://reviews.llvm.org/D127893
First of all, `LLVM_TOOLS_INSTALL_DIR` put there breaks our NixOS
builds, because `LLVM_TOOLS_INSTALL_DIR` defined the same as
`CMAKE_INSTALL_BINDIR` becomes an *absolute* path, and then when
downstream projects try to install there too this breaks because our
builds always install to fresh directories for isolation's sake.
Second of all, note that `LLVM_TOOLS_INSTALL_DIR` stands out against the
other specially crafted `LLVM_CONFIG_*` variables substituted in
`llvm/cmake/modules/LLVMConfig.cmake.in`.
@beanz added it in d0e1c2a550 to fix a
dangling reference in `AddLLVM`, but I am suspicious of how this
variable doesn't follow the pattern.
Those other ones are carefully made to be build-time vs install-time
variables depending on which `LLVMConfig.cmake` is being generated, are
carefully made relative as appropriate, etc. etc. For my NixOS use-case
they are also fine because they are never used as downstream install
variables, only for reading not writing.
To avoid the problems I face, and restore symmetry, I deleted the
exported and arranged to have many `${project}_TOOLS_INSTALL_DIR`s.
`AddLLVM` now instead expects each project to define its own, and they
do so based on `CMAKE_INSTALL_BINDIR`. `LLVMConfig` still exports
`LLVM_TOOLS_BINARY_DIR` which is the location for the tools defined in
the usual way, matching the other remaining exported variables.
For the `AddLLVM` changes, I tried to copy the existing pattern of
internal vs non-internal or for LLVM vs for downstream function/macro
names, but it would good to confirm I did that correctly.
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D117977
Export the driver-template.cpp.in file so that tools using
GENERATE_DRIVER work in standalone builds (currently only relevant
for clang). I've given the file an llvm- prefix, as we're now
searching for the file in CMAKE_MODULE_PATH.
Differential Revision: https://reviews.llvm.org/D127384
After f06abbb393 I have been seeing build
failures due to the obj.clang target missing a dependency on
tools/clang/clang-tablegen-targets.
This appears to be due to the fact that LLVM_COMMON_DEPENDS are not added
as dependencies to the object library.
This patch uses the same logic as llvm_add_library to register
dependencies for object libraries.
Reviewed By: beanz, abrachet, steven_wu
Differential Revision: https://reviews.llvm.org/D127318
On most platforms, the linker detection command that we run ends up being
something like `clang++ -Wl,-v` or `clang++ -Wl,--version`. This usually
fails with a missing reference to `_main` because we don't have any input
file. However, when compiling for a target that is implicitly freestanding,
the invocation actually succeeds and a dummy `a.out` file is created in
the current working directory. This is extremely annoying because it
creates a `a.out` file at the root of the monorepo when running CMake
configuration from the root.
Differential Revision: https://reviews.llvm.org/D125827
This patch adds an llvm-driver multicall tool that can combine multiple
LLVM-based tools. The build infrastructure is enabled for a tool by
adding the GENERATE_DRIVER option to the add_llvm_executable CMake
call, and changing the tool's main function to a canonicalized
tool_name_main format (i.e. llvm_ar_main, clang_main, etc...).
As currently implemented llvm-driver contains dsymutil, llvm-ar,
llvm-cxxfilt, llvm-objcopy, and clang (if clang is included in the
build).
llvm-driver can be enabled from builds by setting
LLVM_TOOL_LLVM_DRIVER_BUILD=On.
There are several limitations in the current implementation, which can
be addressed in subsequent patches:
(1) the multicall binary cannot currently properly handle
multi-dispatch tools. This means symlinking llvm-ranlib to llvm-driver
will not properly result in llvm-ar's main being called.
(2) the multicall binary cannot be comprised of tools containing
conflicting cl::opt options as the global cl::opt option list cannot
contain duplicates.
These limitations can be addressed in subsequent patches.
Differential revision: https://reviews.llvm.org/D109977
This makes it possible to crosscompile runtimes with cl.exe on Windows.
An external project is completely misconfigured otherwise because
cmake_args is set only for native builds or builds crosscompiled with
clang.
Differential Revision: https://reviews.llvm.org/D122578
Reviewed By: beanz, compnerd
This reverts commit ec10ac750a.
See https://discourse.llvm.org/t/cmake-regeneration-is-broken/62788.
This change caused Ninja's CMake regeneration to depend on the build,
which prevented CMake regeneration from functioning properly and caused
spurious build failures on incremental builds when a CMake change
occurred.
Currently, LLVM's LineEditor and LLDB both use libedit, but find them in different (inconsistent) ways.
This causes issues e.g. when you are using a locally installed version of libedit, which will not be used
by clang-query, but by lldb if picked up by FindLibEdit.cmake
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D124673
https://reviews.llvm.org/D124075 causes MLIR to no longer build
when using make rather than ninja, due to a tablegen-generated
header being used before it is created.
It seems that this is related to the use of LLVM_ENABLE_OBJLIB when
using add_tablgen with a non-Ninja/Xcode generator. In that case an
intermediate objlib target is generated.
This patch fixes the issue by a) declaring dependencies in
add_tablegen for mlir-pdll and b) making sure those dependencies
are added to the objlib target.
Differential Revision: https://reviews.llvm.org/D125010
The mechanism behind "check-all" is recording params of add_lit_testsuite()
calls in global variables LLVM_LIT_*, and then creating an extra suite with
their union at the end.
This avoids composing the check-* targets directly, which doesn't work well.
We generalize this by allowing multiple families of variables LLVM_{name}_LIT_*:
umbrella_lit_testsuite_begin(check-foo)
... test suites here will be added to LLVM_FOO_LIT_* variables ...
umbrella_lit_testsuite_end(check-foo)
(This also moves some implementation muck out of {llvm,clang}/CMakeLists.txt
This patch also changes check-clang-tools to use be an umbrella test target,
which means the clangd and clang-pseudo tests are included in it, along with the
the other testsuites that already are (like check-clang-extra-clang-tidy).
Differential Revision: https://reviews.llvm.org/D121838
D77110 initially added support for setting LLVM_CONFIG_DEFAULT_EXTERNAL_LIT
to llvm-lit in the install directory if LLVM_INSTALL_UTILS is on.
D79144 ensured that, on Windows, llvm-lit.py is correctly set for
LLVM_CONFIG_DEFAULT_EXTERNAL_LIT within the context of the build area,
however, it did not account for the install area which is the latter set
directive for this same variable.
This patch ensures that LLVM_CONFIG_DEFAULT_EXTERNAL_LIT under the install
area uses llvm-lit.py under Windows since llvm-lit without the extension
is not created.
Differential Revision: https://reviews.llvm.org/D124197
Add a new CMake file to expand on for more problematic configurations
in the future.
Related to #54645
Reviewed By: beanz, phosek, smeenai
Differential Revision: https://reviews.llvm.org/D123777
We've found that there are cases where it's useful to be able to include
the same target in multiple distributions (e.g. if you want a
distribution that's a superset of another distribution, for convenience
purposes), and that there are cases where the distribution of a target
and its umbrella can legitimately differ (e.g. the LTO library would
commonly be distributed alongside your tools, but it also falls under
the llvm-libraries umbrella, which would commonly be distributed
separately). Relax the restrictions while providing an option to restore
them (which is mostly useful to ensure you aren't accidentally placing
targets in the wrong distributions).
There could be further refinements here (e.g. excluding a target from an
umbrella if it's explicitly included in some other distribution, or
having variables to control which targets are allowed to be duplicated
or placed in a separate distribution than their umbrellas), but we can
punt on those until there's an actual need.
Place PersistentId declaration under #if LLVM_ENABLE_ABI_BREAKING_CHECKS to
reduce memory usage when it is not needed.
Differential Revision: https://reviews.llvm.org/D120714
Or rather, error out if it is set to something other than ON. This
removes the ability to enable the legacy pass manager by default,
but does not remove the ability to explicitly enable it through
various flags like -flegacy-pass-manager or -enable-new-pm=0.
I checked, and our test suite definitely doesn't pass with
LLVM_ENABLE_NEW_PASS_MANAGER=OFF anymore.
Differential Revision: https://reviews.llvm.org/D123126
This option tells the host clang to use the new pass manager.
Given that it's been the default for a while, this seems unnecessary.
This was added in D57068.
(this does not affect any LLVM/Clang functionality)
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D122947
CLANG_TOOLS_DIR holds the the current bin/ directory, maybe with a %(build_mode)
placeholder. It is used to add the just-built binaries to $PATH for lit tests.
In most cases it equals LLVM_TOOLS_DIR, which is used for the same purpose.
But for a standalone build of clang, CLANG_TOOLS_DIR points at the build tree
and LLVM_TOOLS_DIR points at the provided LLVM binaries.
Currently CLANG_TOOLS_DIR is set in clang/test/, clang-tools-extra/test/, and
other things always built with clang. This is a few cryptic lines of CMake in
each place. Meanwhile LLVM_TOOLS_DIR is provided by configure_site_lit_cfg().
This patch moves CLANG_TOOLS_DIR to configure_site_lit_cfg() and renames it:
- there's nothing clang-specific about the value
- it will also replace LLD_TOOLS_DIR, LLDB_TOOLS_DIR etc (not in this patch)
It also defines CURRENT_LIBS_DIR. While I removed the last usage of
CLANG_LIBS_DIR in e4cab4e24d, there are LLD_LIBS_DIR usages etc that
may be live, and I'd like to mechanically update them in a followup patch.
Differential Revision: https://reviews.llvm.org/D121763
This ensures that Tests.cmake is tracked by Ninja and any changes to
this file from the subbuilds are correctly detected.
Differential Revision: https://reviews.llvm.org/D121647
If libcurl was built with CMake, CMake's FindCURL module defers
completely to the included config file. This config file doesn't set any
of the variables that the current check script depends on; it just sets
up an imported CMake target. Accordingly, the smoke test fails, since it
can't find the libcurl (or its static dependencies).
This changes the compile smoke test to refer to the imported library
instead; this should in turn bring in the necessary include and library
directories via the interface properties set up by CMake. This better
mirrors the way libcurl is referred to elsewhere in the CMakeLists.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D121718
This support "DEPENDS" and "EXTRA_INCLUDES", allowing in particular
to inject include paths to a tablegen targets without forcing to go
through the global INCLUDE_DIRECTORIES property.
Differential Revision: https://reviews.llvm.org/D121568
This allows you to set a custom path to the ThinLTO cache so that
it can be shared when building in several different build directories.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D121215
This clarifies that this is an LLVM specific variable and avoids
potential conflicts with other projects.
Differential Revision: https://reviews.llvm.org/D119918
Now that our minimum required CMake version is past 3.6, we can use
CMAKE_TRY_COMPILE_PLATFORM_VARIABLES instead of relying on environment
variable trickery. The two aren't entirely equivalent because
CMAKE_TRY_COMPILE_PLATFORM_VARIABLES is only used for try_compiles of
source files and not whole projects, but I ran LLVM configures before
and after this change and the generated CMakeCache.txt files were
identical, so this should be NFC for us.
Reviewed By: thakis
Differential Revision: https://reviews.llvm.org/D121035
We were relying on HandleLLVMOptions adding this flag, but that's not
included in compiler-rt. Add the flag explicitly ourselves to ensure
it's present; the duplication of the flag in the parts of the build
which do include HandleLLVMOptions doesn't cause any issues.
Reviewed By: ychen
Differential Revision: https://reviews.llvm.org/D121033
The upstream project ships CMake rules for building vanilla gtest/gmock which conflict with the names chosen by LLVM. Since LLVM's build rules here are quite specific to LLVM, prefixing them to avoid collision is the right thing (i.e. there does not appear to be a path to letting someone *replace* LLVM's googletest with one they bring, so co-existence should be the goal).
This allows LLVM to be included with testing enabled within projects that themselves have a dependency on an official gtest release.
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D120789
- Using LLVM_WINSYSROOT would pick up DIA SDK path automatically,
otherwise llvm-pdbutil has no DIA support.
- Add MSVC_VER to specify VC tools version.
- Make MSVC_VER/WINSDK_VER optional. If not specified, use the highest
version number like the driver does.
Reviewed By: thakis
Differential Revision: https://reviews.llvm.org/D117852
Remove the dependency on ounit2 and the relevant lit code. It seems
that ounit2 is not used at all and all OCaml binding tests pass without
it installed.
Thanks for Shiwei Weng and Josh Berdine for bringing this to
my attention.
Differential Revision: https://reviews.llvm.org/D119884
Apparently modern versions of ounit2 can only be found as "ounit2"
rather than "oUnit" version 2. Update the CMake check to support both
variants. This makes the OCaml tests run again with ounit2-2.2.4.
Differential Revision: https://reviews.llvm.org/D119079
This updates all the non-runtime project release notes to use the
version number from CMake instead of the hard-coded version numbers
in conf.py.
It also hides warnings about pre-releases when the git suffix
is dropped from the LLVM version in CMake.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D112181
As raised here: https://lists.llvm.org/pipermail/llvm-dev/2021-November/153881.html
Now that VS2022 is on general release, LLVM is expected to build on VS2017, VS2019 and VS2022, which is proving hazardous to maintain due to changes in behaviour including preprocessor and constexpr changes. Plus of the few developers that work with VS, many have already moved to VS2019/22.
This patch proposes to raise the minimum supported version to VS2019 (16.x) - I've made the hard limit 16.0 or later, with the soft limit VS2019 16.7 - older versions of VS2019 are "allowed" (at your own risk) via the LLVM_FORCE_USE_OLD_TOOLCHAIN cmake flag.
Differential Revision: https://reviews.llvm.org/D114639
We previously had a few varied definitions of this floating around.
I had tried to make the one installed with LLVM handle all the cases, and then made the others use it, but this ran into issues with `HandleOutOfTreeLLVM` not working for compiler-rt, and also `CMAKE_EXE_LINKER_FLAGS` not working right without `CMP0056` set to the new behavior.
My compromise solution is this:
- No not completely deduplicate: the runtime libs will instead use a version that still exists as part of the internal and not installed common shared CMake utilities. This avoids `HandleOutOfTreeLLVM` or a workaround for compiler-rt.
- Continue to use `CMAKE_REQUIRED_FLAGS`, which effects compilation and linking. Maybe this is unnecessary, but it's safer to leave that as a future change. Also means we can avoid `CMP0056` for now, to try out later, which is good incrementality too.
- Call it `llvm_check_compiler_linker_flag` since it, in fact is about both per its implementation (before and after this patch), so there is no name collision.
In the future, we might still enable CMP0056 and make compiler-rt work with HandleOutOfTreeLLVM, which case we delete `llvm_check_compiler_flag` and go back to the old way (as these are, in fact, linking related flags), but that I leave for someone else as future work.
The original issue was reported to me in https://reviews.llvm.org/D116521#3248117 as
D116521 made clang and LLVM use the common cmake utils.
Reviewed By: sebastian-ne, phosek, #libunwind, #libc, #libc_abi, ldionne
Differential Revision: https://reviews.llvm.org/D117537
* Use `MATCHES` so that `Ninja Multi-Config` generator also satisfies the Ninja check
* Pull out a couple of values into variables, inside `function(tablegen project ofn)`, NFC
Differential Revision: https://reviews.llvm.org/D118100
since it qualifies as a toolchain tool rather than "internal llvm tool".
This will make it part of builds which set the
LLVM_INSTALL_TOOLCHAIN_ONLY cmake option, such as the Windows installer.
Differential revision: https://reviews.llvm.org/D118042
/INCREMENTAL is the linker default (lld-link and MSVC link). Specifying
"/INCREMENTAL:NO" is the only way to disable it. So checking for the
negative flag instead and check exe/module/shared link flags
independently.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D117381
If `CMAKE_INSTALL_BINDIR` is a different absolute path per project, as
it is with NixOS when we install every package to its own prefix, the
old way fails when the absolute path gets prepended.
There are still some issues with dowstream packages using `LLVM_TOOLS_INSTALL_DIR` which also may be absolute and just for LLVM proper, but that will be addressed in a future commit.
Differential Revision: https://reviews.llvm.org/D101070
We previously had a few varied definitions of this floating around. I made the one installed with LLVM handle all the cases, and then made the others use it.
This issue was reported to me in https://reviews.llvm.org/D116521#3248117 as
D116521 made clang and llvm use the common cmake utils.
Reviewed By: sebastian-ne, phosek, #libunwind, #libc, #libc_abi, ldionne
Differential Revision: https://reviews.llvm.org/D117537
The tensorflow AOT compiler can cross-target, but it can't run on (for
example) arm64. We added earlier support where the AOT-ed header and object
would be built on a separate builder and then passed at build time to
a build host where the AOT compiler can't run, but clang can be otherwise
built.
To simplify such scenarios given we now support more than one AOT-able
case (regalloc and inliner), we make the AOT scenario centered on whether
files are generated, case by case (this includes the "passed from a
different builder" scenario).
This means we shouldn't need an 'umbrella' LLVM_HAVE_TF_AOT, in favor of
case by case control. A builder can opt out of an AOT case by passing that case's
model path as `none`. Note that the overrides still take precedence.
This patch controls conditional compilation with case-specific flags,
which can be enabled locally, for the component where those are
available. We still keep an overall flag for some tests.
The 'development/training' mode is unchanged, because there the model is
passed from the command line and interpreted.
Differential Revision: https://reviews.llvm.org/D117752
This is the original patch in my GNUInstallDirs series, now last to merge as the final piece!
It arose as a new draft of D28234. I initially did the unorthodox thing of pushing to that when I wasn't the original author, but since I ended up
- Using `GNUInstallDirs`, rather than mimicking it, as the original author was hesitant to do but others requested.
- Converting all the packages, not just LLVM, effecting many more projects than LLVM itself.
I figured it was time to make a new revision.
I have used this patch series (and many back-ports) as the basis of https://github.com/NixOS/nixpkgs/pull/111487 for my distro (NixOS), which was merged last spring (2021). It looked like people were generally on board in D28234, but I make note of this here in case extra motivation is useful.
---
As pointed out in the original issue, a central tension is that LLVM already has some partial support for these sorts of things. Variables like `COMPILER_RT_INSTALL_PATH` have already been dealt with. Variables like `LLVM_LIBDIR_SUFFIX` however, will require further work, so that we may use `CMAKE_INSTALL_LIBDIR`.
These remaining items will be addressed in further patches. What is here is now rote and so we should get it out of the way before dealing more intricately with the remainder.
Reviewed By: #libunwind, #libc, #libc_abi, compnerd
Differential Revision: https://reviews.llvm.org/D99484
This is the original patch in my GNUInstallDirs series, now last to merge as the final piece!
It arose as a new draft of D28234. I initially did the unorthodox thing of pushing to that when I wasn't the original author, but since I ended up
- Using `GNUInstallDirs`, rather than mimicking it, as the original author was hesitant to do but others requested.
- Converting all the packages, not just LLVM, effecting many more projects than LLVM itself.
I figured it was time to make a new revision.
I have used this patch series (and many back-ports) as the basis of https://github.com/NixOS/nixpkgs/pull/111487 for my distro (NixOS), which was merged last spring (2021). It looked like people were generally on board in D28234, but I make note of this here in case extra motivation is useful.
---
As pointed out in the original issue, a central tension is that LLVM already has some partial support for these sorts of things. Variables like `COMPILER_RT_INSTALL_PATH` have already been dealt with. Variables like `LLVM_LIBDIR_SUFFIX` however, will require further work, so that we may use `CMAKE_INSTALL_LIBDIR`.
These remaining items will be addressed in further patches. What is here is now rote and so we should get it out of the way before dealing more intricately with the remainder.
Reviewed By: #libunwind, #libc, #libc_abi, compnerd
Differential Revision: https://reviews.llvm.org/D99484
Clang 13 has a -fsanitize-coverage -fno-semantic-interposition bug (D117190)
which may lead to
`relocation R_X86_64_PC32 cannot be used against symbol` linker error
in -DLLVM_USE_SANITIZE_COVERAGE=ON build when a shared object is built (e.g.
-DLLVM_BUILD_LLVM_DYLIB=on).
For simplicity, just disallow Clang 13 entirely.
Note: GCC -fPIC performance benefits from -fno-semantic-interposition
dramatically. Clang benefits little. Using this option is more for a dogfood
purpose to test correctness of this option, because in the wild some important
packages like CPython uses this option.
Differential Revision: https://reviews.llvm.org/D117183
This diff enables users to override CMAKE_C_ARCHIVE_CREATE & CMAKE_CXX_ARCHIVE_CREATE
(currently set in HandleLLVMOptions.cmake).
For example, one can specify
cmake -DCMAKE_C_ARCHIVE_CREATE="<CMAKE_AR> TDqc <TARGET> <LINK_FLAGS> <OBJECTS>" \
-DCMAKE_CXX_ARCHIVE_CREATE="<CMAKE_AR> TDqc <TARGET> <LINK_FLAGS> <OBJECTS>" ...
to make the build create thin archives instead of regular ones.
For a clean run `ninja lld` using thin archives seems to reduce the size
of the build directory from ~14GB to ~8GB
Differential revision: https://reviews.llvm.org/D116850
This is the patch for LLVM proper in my series for adding GNUInstallDirs support in all project.
Additionally:
Create a new `CACHE STRING` variable, `LLVM_EXAMPLES_INSTALL_DIR`, to control where the examples are installed on analogy with the other variables.
---
This patch supersedes D28234, which tried to do the same thing but hand-rolled without GNUInstallDirs.
This patch nearly reverts commit 3 0fc88bf1dc15a72e2d9809d28019d386b7a7cc0, which was a revert of a prior attempt."
(I had to add a space here or else Phabricator detects a reference cycle and won't let me do the form submit.)
Reviewed By: compnerd
Differential Revision: https://reviews.llvm.org/D100810
Users could pass flags by environment variables like CFLAGS/CXXFLAGS/LDFLAGS
or by using CMAKE_<LANG>_FLAGS_INIT/CMAKE_<t>_LINKER_FLAGS_INIT. So this
toolchain file should append to INIT flags instead. Otherwise, user
flags would be discarded here by assigning to CMAKE_<LANG>_FLAGS
directly.
Reviewed By: smeenai, mstorsjo
Differential Revision: https://reviews.llvm.org/D116709
@beanz tells me it should in fact exists, and it would be bad to put a
list of dirs in `LLVM_LIBRARY_DIR`. I am therefore making some changes
to help avoid this an other mistakes:
- Use a separate `LLVM_CONFIG_LIBRARY_DIR` (no "S") variable so we don't
start putting a list in `LLVM_LIBRARY_DIR` by mistake.
- Define the individual dir variables first, and the define the list of
dirs variables programmatically.
Also, I rearranged the definitions of the "regular" single dirs below so
`LLVM_BINARY_DIR`, which is the unsuffixed one, comes first before the
suffixed ones.
Reviewed By: beanz
Differential Revision: https://reviews.llvm.org/D116497
See the docs in the new function for details.
I think I found every instance of this copy pasted code. Polly could
also use it, but currently does something different, so I will save the
behavior change for a future revision.
We get the shared, non-installed CMake modules following the pattern
established in D116472.
It might be good to have LLD and Flang also use this, but that would be
a functional change and so I leave it as future work.
Reviewed By: beanz, lebedev.ri
Differential Revision: https://reviews.llvm.org/D116521
Include the value of `ZLIB_ROOT` in `LLVMConfig.cmake` so `FindZLIB` can pick it up. This fixes an issue where ZLIB is not found on AIX runtimes despite specifying `-DZLIB_ROOT`.
Reviewed By: daltenty
Differential Revision: https://reviews.llvm.org/D116235
Add CMake variable LLVM_EXTERNAL_PROJECT_BUILD_TOOL_ARGS to allow
arguments to be passed to the native tool used in CMake --build
invocations for external projects.
Can be used to pass extra arguments for enhanced versions of build
tools, e.g. distributed build options.
Differential Revision: https://reviews.llvm.org/D115815
As Visual Studio's CMake support is getting better and better the line
between IDE generator and non-IDE generators is blurring. Visual Studio
2019 and later have a very useful UI that can handle all of the various
targets we create, but if they are unsorted it is wildly unwieldy.
This change sorts the lit testsuite targets and per-component install
targets into folders, which are not generated for IDE generators but
are generated by default under Visual Studio's CMake + Ninja
integration.
This reverts 8cb7876cb3 and follow-ups.
GNU ld/gold/ld.lld -O has nothing to do with any code related linker optimizations.
It has very small benefit (save 144Ki (.hash, .gnu_hash) with GNU ld, save 0.7%
.debug_str with gold/ld.lld) while it makes gold/ld.lld significantly slower
when linking RelWithDebInfo clang (gold: 16.437 vs 19.488; ld.lld: 1.882 vs 4.881).
When looking at building the generator for regalloc, we realized we'd
need quite a bit of custom logic, and that perhaps it'd be easier to
just have each usecase (each kind of mlgo policy) have it's own
stand-alone test generator.
This patch just consolidates the old `config.py` and
`generate_mock_model.py` into one file, and does away with
subdirectories under Analysis/models.
This reverts 3816c53f04 and removes follow-up
fixups.
The original intention was to show error earlier (posix_fallocate time) than
later for ld.lld but it appears to cause some problems which make it not free.
* FreeBSD ZFS: EINVAL, not too bad.
* FreeBSD UFS: according to khng "devastatingly slow on freebsd because UFS on freebsd does not have preallocation support like illumos. It zero-fills."
* NetBSD: maybe EOPNOTSUPP
* Linux tmpfs: unless tmpfs is set up to use huge pages (requires CONFIG_TRANSPARENT_HUGE_PAGECACHE=y), I can consistently demonstrate ~300ms delay for a 1.4GiB output.
* Linux ext4: I don't measure any benefit, either backed by a hard disk or by a file in tmpfs.
* The current code organization of `defined(HAVE_POSIX_FALLOCATE)` costs us a macro dispatch for AIX.
I think we should just remove it. I think if posix_fallocate ever finds demonstrable benefit,
it is likely Linux specific and will not need HAVE_POSIX_FALLOCATE, and possibly opt-in by some specific programs.
In a filesystem with CoW and compression, the ENOSPC benefit may be lost as well.
Reviewed By: khng300
Differential Revision: https://reviews.llvm.org/D115957
See the discussion in D30906 for how it must be robust to downstream
projects that might not use `GNUInstallDirs`.
I think an easier approach is just to include `GNUInstallDirs` so that
we can always rely on it. Looking at its definition in
https://gitlab.kitware.com/cmake/cmake/-/blob/master/Modules/GNUInstallDirs.cmake
it appears safe to include multiple times.
I am trying this out because we will face the same problem many times
over if we use `GNUInstallDirs` more widely, as proposed in D99484 and
its parent revisions, since we do not know what downstream projects do
and rather not break them.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D115601
Just defensive CMake-ing. I pulled this from D115544 and D99484 which
are blocked on some lldb CI failures I don't yet understand. Hoping to land
something smaller in the meantime.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D115566
This reverts commit 492de35df4.
I tried to apply John's changes in 8d897ec915 that were expected to
fix his patch but that didn't work unfortunately.
Reverting this again to fix the macOS bots and leave him more time to
investigate the issue.
This reverts commit 797b50d4be.
See the original D99484. @mib who noticed the original problem could not longer
reproduce it, after I tried and also failed. We are threfore hoping it went
away on its own!
Reviewed By: mib
Differential Revision: https://reviews.llvm.org/D115544
Improves cross-distro portability of LLVM cmake package by resolving paths for
terminfo and libffi via import targets.
When LLVMExports.cmake is generated for installation, it contains absolute
library paths which are likely to be a common cause of portability issues. To
mitigate this, the discovery logic for these dependencies is refactored into
find modules which get installed alongside LLVMConfig.cmake. The result is
cleaner, cmake-friendly management of these dependencies that respect the
environment of the LLVM package importer.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D114327
This patch changes it to ignorelist and contains a filename change for the
.txt file that's called.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D113689
When cross-compiling LLVM in an environment where there //is// an
objdump binary available but it does not understand the target
platform's object file format, extract_symbols.py fails, because its
initial check for tool availability decides that the existence of
objdump at all is good enough to settle on it as the tool of choice.
In such an environment it's useful to work around this by telling
extract_symbols.py to use llvm-readobj instead. The script itself has
an option for that, but its invocation in AddLLVM.cmake wasn't
providing a mechanism to add extra options passed through for the
cmake command line.
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D113557
Add a warning to TableGen for unused template arguments in classes and
multiclasses, for example:
multiclass Foo<int x> {
def bar;
}
$ llvm-tblgen foo.td
foo.td:1:20: warning: unused template argument: Foo::x
multiclass Foo<int x> {
^
A flag '--no-warn-on-unused-template-args' is added to disable the
warning. The warning is disabled for LLVM and sub-projects if
'LLVM_ENABLE_WARNINGS=OFF'.
Reviewed By: RKSimon
Differential Revision: https://reviews.llvm.org/D109359
LLVM_LINKER_IS_LLD is now set with LLVM_ENABLE_LLD=ON (or LLVM_USER_LINKER=lld)
even on APPLE, and we pass -Wl,-order_file when LLVM_LINKER_IS_LLD on APPLE
too.
To make this straightforward, change the linker detection logic to go through
the compiler driver on APPLE like on the other platforms.
No intended behavior change if LLVM_ENABLE_LLD isn't set.
Differential Revision: https://reviews.llvm.org/D113021
Cole Kissane