* 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
This is a new draft of D28234. I previously did the unorthodox thing of
pushing to it when I wasn't the original author, but since this version
- Uses `GNUInstallDirs`, rather than mimics it, as the original author
was hesitant to do but others requested.
- Is much broader, effecting many more projects than LLVM itself.
I figured it was time to make a new revision.
I am using this patch (and many back-ports) as the basis of
https://github.com/NixOS/nixpkgs/pull/111487 for my distro (NixOS). 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. For example
`LLVM_LIBDIR_SUFFIX`, or `COMPILER_RT_INSTALL_PATH`. Because it's not
quite clear yet what to do about those, we are holding off on changing
libdirs and `compiler-rt`. for this initial PR.
---
On the advice of @lebedev.ri, I am splitting this up a bit per
subproject, starting with LLVM. To allow it to be more easily reviewed. This and the subsequent patch must be landed together, as this will not build alone. But the rest can be landed on their own.
Reviewed By: compnerd
Differential Revision: https://reviews.llvm.org/D100810
Forward the LLVM_ENABLE_RUNTIMES cmake variable in the cross compilation
invocation.
Now that passing libcxx must be specified in LLVM_ENABLE_RUNTIMES
instead of LLVM_ENABLE_PROJECTS, the LLDB's sanity check for libcxx
trips up (in the cross compilation case) because the runtimes are not
forwarded. This patch fixes that.
Differential revision: https://reviews.llvm.org/D112855
The xar file format has been deprecated since macOS 12.0, causing a
warning to be printed:
warning: 'xar_open' is deprecated: first deprecated in macOS 12.0 -
xar is a deprecated file format and should not be used.
Disable xar support when the macosx deployment target is greater or
equal to 12.0.
Differential revision: https://reviews.llvm.org/D112849
- Both LLVM_REQUIRES_RTTI and LLVM_REQUIRES_EH are internal flags that
individual targets can use to force RTTI/EH. Turning off
LLVM_REQUIRES_RTTI should honor if that variable is set explicitly for
an individual target.
Argyrios Kyrtzidis