This is catching misconfiguration. For example one of my automation
had a typo running `-DLLVM_ENABLE_PROJECTS=nlir` and it was just
silently ignored. Instead, an error will now be displayed.
Recommit 4121ac1e after fixing it to not fail on "all"
Differential Revision: https://reviews.llvm.org/D110016
```
CMake Error at CMakeLists.txt:76 (MESSAGE):
all isn't a know project:
clang;clang-tools-extra;compiler-rt;cross-project-tests;libc;libclc;libcxx;libcxxabi;libunwind;lld;lldb;mlir;openmp;parallel-libs;polly;pstl;flang;llvm
```
This reverts commit 4121ac1e7f.
This is catching misconfiguration. For example one of my automation
had a typo running `-DLLVM_ENABLE_PROJECTS=nlir` and it was just
silently ignored. Instead, an error will now be displayed.
Differential Revision: https://reviews.llvm.org/D110016
This way, we do not need to set LLVM_CMAKE_PATH to LLVM_CMAKE_DIR when (NOT LLVM_CONFIG_FOUND)
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D107717
This makes the default build closer to a -DLLVM_ENABLE_RUNTIMES=all build.
The layout is arguably superior because different libraries of target triples
are in different directories, similar to GCC/Debian multiarch.
When LLVM_DEFAULT_TARGET_TRIPLE is x86_64-unknown-linux-gnu,
`lib/clang/14.0.0/lib/libclang_rt.asan-x86_64.a`
is moved to
`lib/clang/14.0.0/lib/x86_64-unknown-linux-gnu/libclang_rt.asan.a`.
In addition, if the host compiler supports -m32 (multilib),
`lib/clang/14.0.0/lib/libclang_rt.asan-i386.a`
is moved to
`lib/clang/14.0.0/lib/i386-unknown-linux-gnu/libclang_rt.asan.a`.
Clang has been detecting both paths for lib/Driver/ToolChains/Gnu.cpp since 2018 (D50547).
---
Note: Darwin needs to be disabled. The hierarchy needs to be sorted out.
The current -DLLVM_DEFAULT_TARGET_TRIPLE=off state is like:
```
lib/clang/14.0.0/lib/darwin/libclang_rt.profile_ios.a
lib/clang/14.0.0/lib/darwin/libclang_rt.profile_iossim.a
lib/clang/14.0.0/lib/darwin/libclang_rt.profile_osx.a
```
Windows needs to be disabled: https://reviews.llvm.org/D107799?id=368557#2963311
Differential Revision: https://reviews.llvm.org/D107799
This is a pretty small bit of CMake goop to generate code coverage
reports. I always forget the right script invocation and end up
fumbling around too much.
Wouldn't it be great to have targets that "Just Work"?
Well, I thought so.
At present this only really works correctly for LLVM, but I'll extend
it in subsequent patches to work for subprojects.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D109019
LLVM_ENABLE_NEW_PASS_MANAGER is set to ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER, so
-DLLVM_ENABLE_NEW_PASS_MANAGER=off has no effect.
Change the cache variable to LLVM_ENABLE_NEW_PASS_MANAGER instead.
A user opting out the new PM needs to switch from
-DENABLE_EXPERIMENTAL_NEW_PASS_MANAGER=off to
-DLLVM_ENABLE_NEW_PASS_MANAGER=off.
Also give a warning that -DLLVM_ENABLE_NEW_PASS_MANAGER=off is deprecated.
Reviewed By: aeubanks, phosek
Differential Revision: https://reviews.llvm.org/D108775
This makes the default build closer to a -DLLVM_ENABLE_RUNTIMES=all build.
The layout is arguably superior because different libraries of target triples
are in different directories, similar to GCC/Debian multiarch.
When LLVM_DEFAULT_TARGET_TRIPLE is x86_64-unknown-linux-gnu,
`lib/clang/14.0.0/lib/libclang_rt.asan-x86_64.a`
becomes
`lib/clang/14.0.0/lib/x86_64-unknown-linux-gnu/libclang_rt.asan.a`.
Clang has been detecting both paths since 2018 (D50547).
---
Note: Darwin needs to be disabled. The hierarchy needs to be sorted out.
The current -DLLVM_DEFAULT_TARGET_TRIPLE=off state is like:
```
lib/clang/14.0.0/lib/darwin/libclang_rt.profile_ios.a
lib/clang/14.0.0/lib/darwin/libclang_rt.profile_iossim.a
lib/clang/14.0.0/lib/darwin/libclang_rt.profile_osx.a
```
Windows needs to be disabled: https://reviews.llvm.org/D107799?id=368557#2963311
Differential Revision: https://reviews.llvm.org/D107799
This patch removes `f18`, a.k.a. the old driver. It is being replaced
with the new driver, `flang-new`, which has reached feature parity with
`f18` a while ago. This was discussed in [1] and also in [2].
With this change, `FLANG_BUILD_NEW_DRIVER` is no longer needed and is
also deleted. This means that we are making the dependency on Clang permanent
(i.e. it cannot be disabled with a CMake flag).
LIT set-up is updated accordingly. All references to `f18` or `f18.cpp`
are either updated or removed.
The `F18_FC` variable from the `flang` bash script is replaced with
`FLANG_FC`. The former is still supported for backwards compatibility.
[1] https://lists.llvm.org/pipermail/flang-dev/2021-June/000742.html
[2] https://reviews.llvm.org/D103177
Differential Revision: https://reviews.llvm.org/D105811
This should fix build breaks for 'development' mode. The other modes
were unaffected - 'release' because it doesn't use TFUtils.cpp, and the
mixed mode because the AOT compiled code brings in the necessary include
dirs anyway.
It turns out that during training, the time required to parse the
textual protobuf of a training log is about the same as the time it
takes to compile the module generating that log. Using binary protobufs
instead elides that cost almost completely.
Differential Revision: https://reviews.llvm.org/D106157
With this patch, `FLANG_BUILD_NEW_DRIVER` is set to `On` by default
(i.e. the new driver is enabled). Note that the new driver depends on
Clang and hence with this change you will need to add `clang` to
`LLVM_ENABLE_PROJECTS`.
If you don't want to build the new driver, set `FLANG_BUILD_NEW_DRIVER`
to `Off`. This way you won't be required to include `clang` in
`LLVM_ENABLE_PROJECTS`.
Differential Revision: https://reviews.llvm.org/D101842
Using `cmake` >=3.20 results in many warnings about this new policy. This change silences the warnings by explicitly declaring use of the "OLD" behavior.
This policy currently affects only one place: the `tablegen()` function in `TableGen.cmake`.
Differential Revision: https://reviews.llvm.org/D101083
This was prompted by D95727, which had the side-effect to break the
'release' mode build bot for ML-driven policies. The problem is that now
the pre-compiled object files don't get transitively carried through as
'source' anymore; that being said, the previous way of consuming them
was problematic, because it was only working for static builds; in
dynamic builds, the whole tf_xla_runtime was linked, which is
undesirable.
The alternative is to treat tf_xla_runtime as an archive, which then
leads to the desired effect.
Differential Revision: https://reviews.llvm.org/D99829
Call `get_errc_messages` only if `LLVM_INCLUDE_TESTS` was set.
Reviewed By: zero9178, abhina.sreeskantharajan, jhenderson
Differential Revision: https://reviews.llvm.org/D98861
Visual Studios implementation of the C++ Standard Library does not use strerror to produce a message for std::error_code unlike other standard libraries such as libstdc++ or libc++ that might be used.
This patch adds a cmake script that through running a C++ program gets the error messages for the POSIX error codes and passes them onto lit through an optional config parameter.
If the config parameter is not set, or getting the messages failed, due to say a cross compiling configuration without an emulator, it will fall back to using pythons strerror functions.
Differential Revision: https://reviews.llvm.org/D98278
The lit test suite uses python 3.6 features. Rather than a strange
python syntax error upon running the lit tests, we will require the
correct version in CMake.
Reviewed By: serge-sans-paille, yln
Differential Revision: https://reviews.llvm.org/D95635
As suggested by Nico in https://reviews.llvm.org/D96049, move check for libproc
from CMakeLists to config-ix.cmake
Reviewed By: thakis
Differential Revision: https://reviews.llvm.org/D96713
Note: Also removes the CMAKE_REQUIRED_LIBRARIES which doesn't appear to
be necessary.
In addition to wall time etc. this should allow us to get less noisy
values for time measurements.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D96049
This turns on the new pass manager by default for the optimization pipeline in
Clang and ThinLTO in various LLD backends. This also makes uses of `opt
-instcombine` use the new pass manager (unless specifically opted out).
This does not affect the backend target-dependent codegen pipeline.
If this causes regressions, you can opt out of the new pass manager
either via the -DENABLE_EXPERIMENTAL_NEW_PASS_MANAGER=OFF CMake flag
while building LLVM, or via various compiler flags, e.g.
-flegacy-pass-manager for Clang or -Wl,--lto-legacy-pass-manager for
ELF LLD. Please file bugs for any regressions.
Major differences:
* The inliner works slightly differently
* -O1 does some amount of inlining
* LCSSA and LoopSimplify are run before all loop passes
* Loop unswitching is implemented slightly differently
* A new SpeculateAroundPHIs pass is added to the pipeline
https://lists.llvm.org/pipermail/llvm-dev/2021-January/148098.html
Reviewed By: asbirlea, ychen, MaskRay, echristo
Differential Revision: https://reviews.llvm.org/D95380
LLVM_TARGETS_TO_BUILD accepts both "host" or "Native" for auto-selecting
the target from the environment. However the way "Native" was plumbed
would lead to the JIT environment being disabled. This patch is making
"Native" works just as "host".
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D95837
Previously, CMake would find any version of Python3. However, the project
claims to require 3.6 or greater, and 3.6 features are being used.
Reviewed By: yln
Differential Revision: https://reviews.llvm.org/D95635
cmake_minimum_required(VERSION) calls cmake_policy(VERSION),
which sets all policies up to VERSION to NEW.
LLVM started requiring CMake 3.13 last year, so we can remove
a bunch of code setting policies prior to 3.13 to NEW as it
no longer has any effect.
Reviewed By: phosek, #libunwind, #libc, #libc_abi, ldionne
Differential Revision: https://reviews.llvm.org/D94374
Remove the hack adding /usr/local paths on FreeBSD and DragonFlyBSD.
It does not seem to be necessary today, and it breaks cross builds.
Differential Revision: https://reviews.llvm.org/D94491
This is needed for cross-compiling LLVM from Cygwin, but it had gotten
deleted in rG2724d9e12960cc1d93eeabbfc9aa1bffffa041cc
Reviewed By: compnerd
Differential Revision: https://reviews.llvm.org/D92336
This allows us to use its value everywhere, rather than just clang. Some
other places, like opt and lld, will use its value soon.
Rename it internally to LLVM_ENABLE_NEW_PASS_MANAGER.
The #define for it is now in llvm-config.h.
The initial land accidentally set the value of
LLVM_ENABLE_NEW_PASS_MANAGER to the string
ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER instead of its value.
Reviewed By: rnk, hans
Differential Revision: https://reviews.llvm.org/D92072
This allows us to use its value everywhere, rather than just clang. Some
other places, like opt and lld, will use its value soon.
The #define for it is now in llvm-config.h.
Reviewed By: rnk, hans
Differential Revision: https://reviews.llvm.org/D92072
No longer rely on an external tool to build the llvm component layout.
Instead, leverage the existing `add_llvm_componentlibrary` cmake function and
introduce `add_llvm_component_group` to accurately describe component behavior.
These function store extra properties in the created targets. These properties
are processed once all components are defined to resolve library dependencies
and produce the header expected by llvm-config.
Differential Revision: https://reviews.llvm.org/D90848
Allow overriding the default set of flags used to enable UBSan when
building llvm.
This can be used to test new checks or opt out of certain checks.
Differential Revision: https://reviews.llvm.org/D89439
The change in 0ba9843397 changed the behaviour of the build when
using an XL build compiler because `-G` is not a pure linker option:
it also implies `-shared`. This was accounted for in the base CMake
configuration, so an analysis of the change from 0ba9843397 in
relation to a build using Clang (where `-shared` is introduced by CMake)
would not identify the issue. This patch resolves this particular issue
by adding `-shared` alongside `-Wl,-G`.
At the same time, the investigation reveals that several aspects of the
various build configurations are not operating in the manner originally
intended.
The other issue related to the `-G` linker option in the build is that
the removal of it (to avoid unnecessary use of run-time linking) is not
effective for the build using the Clang compiler. This patch addresses
this by adjusting the regular expressions used to remove the broadly-
applied `-G`.
Finally, the issue of specifying the export list with `-Wl,` instead of
a compiler option is flagged with a FIXME comment.
Reviewed By: daltenty, amyk
Differential Revision: https://reviews.llvm.org/D90041
1. Emit error for -G driver option on AIX
2. Adjust cmake file to use -Wl,-G instead of -G
On AIX, legacy XL compiler uses -G to produce a shared object enabled
for use with the run-time linker, which has different meanings from what
it is used for in Clang. And in Clang, other targets do not have -G map
to another functionality in their legacy compiler. So this error is more
important when we are on AIX.
Differential Revision: https://reviews.llvm.org/D89897
Also have CMake fails if the user provides a TENSORFLOW_C_LIB_PATH but
we can't find TensorFlow at this path.
At the moment the CMake script tries to figure if TensorFlow is
available on the system and enables support for it. This is in general
not desirable to customize build features this way and instead it is
preferable to let the user opt-in explicitly into the features they want
to enable. This is in line with other optional external dependencies
like Z3.
There are a few reasons to this but amongst others:
- reproducibility: making features "magically" enabled based on whether
we find a package on the system or not makes it harder to handle bug
reports from users.
- user control: they can't have TensorFlow on the system and build LLVM
without TensorFlow right now. They also would suddenly distribute LLVM
with a different set of features unknowingly just because their build
machine environment would change subtly.
Right now this is motivated by a user reporting build failures on their system:
.../mesa-git/llvm-git/src/llvm-project/llvm/lib/Analysis/TFUtils.cpp:23:10: fatal error: tensorflow/c/c_api.h: No such file or directory
23 | #include "tensorflow/c/c_api.h"
| ^~~~~~
It looks like we detected TensorFlow at configure time but couldn't set all the paths correctly.
Differential Revision: https://reviews.llvm.org/D88371
Configure default value of `LLVM_ENABLE_WARNINGS` in `HandleLLVMOptions.cmake`.
`LLVM_ENABLE_WARNINGS` is documented as ON by default, but `HandleLLVMOptions` assumes the default has been set somewhere else. If it has not been explicitly set, then `HandleLLVMOptions` implicitly uses OFF as a default.
This removes the various `option()` declarations in favor of a single declaration in `HandleLLVMOptions`. This will prevent the unwanted use of `-w` that is mentioned in a couple of the comments.
Reviewed By: DavidTruby, #libunwind, JDevlieghere, compnerd
Differential Revision: https://reviews.llvm.org/D87243
LLVM has bumped the minimum required CMake version to 3.13.4, so this has become dead code.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D87189
In GNU ld, gold and LLD, --no-allow-shlib-undefined is the default when
linking an executable. The option disallows unresolved symbols in shared objects.
(gold and LLD catch fewer cases than GNU ld. See D57385 for details)
See D57569 why it is bad idea to use --allow-shlib-undefined for executables [a].
GNU ld traditionally copied DT_NEEDED entries transitively. This was
deemed not good, so GNU ld 2.22 defaulted to --no-copy-dt-needed-entries.
gold and LLD always behave like --no-copy-dt-needed-entries.
rL221530 added -Wl,-allow-shlib-undefined to make some old releases of GNU ld's
--no-copy-dt-needed-entries to actually work.
Due to [a] and [b], this patch drops -Wl,-allow-shlib-undefined.
[b]: In a -DBUILD_SHARED_LIBS=on build, `--as-needed --allow-shlib-undefined`
can unexpectedly suppress some .dynsym entries. The issue can cause
mlir-cpu-runner to fail at runtime. Note, on Debian, gcc newer than (gcc-9-20190125-2) enable
--as-needed by default.
See https://sourceware.org/bugzilla/show_bug.cgi?id=26551 for a reduced example.
Reviewed By: mehdi_amini, echristo
Differential Revision: https://reviews.llvm.org/D86839
Currently it is hard to avoid having LLVM link to the system install of
ncurses, since it uses check_library_exists to find e.g. libtinfo and
not find_library or find_package.
With this change the ncurses lib is found with find_library, which also
considers CMAKE_PREFIX_PATH. This solves an issue for the spack package
manager, where we want to use the zlib installed by spack, and spack
provides the CMAKE_PREFIX_PATH for it.
This is a similar change as https://reviews.llvm.org/D79219, which just
landed in master.
Patch By: haampie
Differential Revision: https://reviews.llvm.org/D85820
This patch optionally replaces the CRT allocator (i.e., malloc and free) with rpmalloc (mixed public domain licence/MIT licence) or snmalloc (MIT licence) or mimalloc (MIT licence). Please note that the source code for these allocators must be available outside of LLVM's tree.
To enable, use `cmake ... -DLLVM_INTEGRATED_CRT_ALLOC=D:/git/rpmalloc -DLLVM_USE_CRT_RELEASE=MT` where `D:/git/rpmalloc` has already been git clone'd from `https://github.com/mjansson/rpmalloc`. The same applies to snmalloc and mimalloc.
When enabled, the allocator will be embeded (statically linked) into the LLVM tools & libraries. This currently only works with the static CRT (/MT), although using the dynamic CRT (/MD) could potentially work as well in the future.
When enabled, this changes the memory stack from:
new/delete -> MS VC++ CRT malloc/free -> HeapAlloc -> VirtualAlloc
to:
new/delete -> {rpmalloc|snmalloc|mimalloc} -> VirtualAlloc
The goal of this patch is to bypass the application's global heap - which is thread-safe thus inducing locking - and instead take advantage of a modern lock-free, thread cache, allocator. On a 6-core Xeon Skylake we observe a 2.5x decrease in execution time when linking a large scale application with LLD and ThinLTO (12 min 20 sec -> 5 min 34 sec), when all hardware threads are being used (using LLD's flag /opt:lldltojobs=all). On a dual 36-core Xeon Skylake with all hardware threads used, we observe a 24x decrease in execution time (1 h 2 min -> 2 min 38 sec) when linking a large application with LLD and ThinLTO. Clang build times also see a decrease in the range 5-10% depending on the configuration.
Differential Revision: https://reviews.llvm.org/D71786
This change extend the CMake files with the necessary additions
to build LLVM for z/OS.
Reviewed By: hubert.reinterpretcast
Differential Revision: https://reviews.llvm.org/D83866
We can just use the definition from config.h. This means we need to move
a few lines around in CMakeLists.txt - the TF_AOT detection needs to be
before the spot we process the config.h.cmake files.
Differential Revision: https://reviews.llvm.org/D84349
Summary:
This allows users of the llvm library discover whether llvm was built
with the tensorflow c API dependency, which helps if using the TFUtils
wrapper, for example.
We don't do the same for the LLVM_HAVE_TF_AOT flag, because that does
not expose any API.
Reviewers: mehdi_amini, davidxl
Subscribers: mgorny, aaron.ballman, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D83746
This reverts commit 9908a3b9f5.
The fix was to exclude the content of TFUtils.h (automatically
included in the LLVM_Analysis module, when LLVM_ENABLE_MODULES is enabled).
Differential Revision: https://reviews.llvm.org/D82817
Summary:
This is an experimental ML-based native size estimator, necessary for
computing partial rewards during -Oz inliner policy training. Data
extraction for model training will be provided in a separate patch.
RFC: http://lists.llvm.org/pipermail/llvm-dev/2020-April/140763.html
Reviewers: davidxl, jdoerfert
Subscribers: mgorny, hiraditya, mgrang, arphaman, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D82817
This is more friendly than the "Unknown CMake command “mlir_tablegen”."
that would be issued instead.
Differential Revision: https://reviews.llvm.org/D80359
After D80096, bots that build clang for distribution and that can't use
system gcc / libstdc++ need to pass a working rpath so that unit test
binaries can run. The method suggested in GettingStarted.rst works fine
for local development, but it results in an absolute local rpath ending
up even in distributed binaries like clang, which is both ugly and
unnecessary.
Add an explicit toggle that can be used to add an rpath only for the
non-distributed binaries that need it.
Differential Revision: https://reviews.llvm.org/D80534
Summary:
Besides just generating and consuming the lists, this includes:
* Calling nm with the right options in extract_symbols.py. Such as not
demangling C++ names, which AIX nm does by default, and accepting both
32/64-bit names.
* Not having nm sort the list of symbols or we may run in to memory
issues on debug builds, as nm calls a 32-bit sort.
* Defaulting to having LLVM_EXPORT_SYMBOLS_FOR_PLUGINS on for AIX
* CMake versions prior to 3.16 set the -brtl linker flag globally on
AIX. Clear it out early on so we don't run into failures. We will set
it as needed.
Reviewers: jasonliu, DiggerLin, stevewan, hubert.reinterpretcast
Reviewed By: hubert.reinterpretcast
Subscribers: hubert.reinterpretcast, mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70972
Relanding this as D79632 should fix the macOS tests with this option.
Original commit:
Summary:
Currently building LLVM on macOS and on other platforms with LLVM_ENABLE_MODULES is using different module flags,
which means that a passing modules build on macOS might fail on Linux and vice versa. -fmodules-local-submodule-visibility
is the mode that has clearer semantics and is closer to the actual C++ module standard, so let's make this the default everywhere.
We can still test building without local submodule visibility on an additional bot by just changing the respective CMake flag. However,
if building without local-submodule-visibility breaks we won't revert other commits and we won't loose LLDB's/Clang's test run
information.
Reviewers: aprantl, bruno, Bigcheese
Reviewed By: Bigcheese
Subscribers: abidh, dexonsmith, JDevlieghere, lldb-commits, mgorny, llvm-commits
Tags: #llvm, #lldb
Differential Revision: https://reviews.llvm.org/D74892
This reverts commit 8baa0b9439. This broke the
LLDB Green Dragon bot where htonl is getting miscompiled on macOS 10.14 and 10.15
SDKs, causing networking tests to fail as IP addressed were being inverted
(e.g., 127.0.0.1 became 1.0.0.127 with an enabled modules build).
Reverting until this is fixed.
This is primarily motivated by the desire to move from Python2 to
Python3. `PYTHON_EXECUTABLE` is ambiguous. This explicitly identifies
the python interpreter in use. Since the LLVM build seems to be able to
completed successfully with python3, use that across the build. The old
path aliases `PYTHON_EXECUTABLE` to be treated as Python3.
Summary:
Currently building LLVM on macOS and on other platforms with LLVM_ENABLE_MODULES is using different module flags,
which means that a passing modules build on macOS might fail on Linux and vice versa. -fmodules-local-submodule-visibility
is the mode that has clearer semantics and is closer to the actual C++ module standard, so let's make this the default everywhere.
We can still test building without local submodule visibility on an additional bot by just changing the respective CMake flag. However,
if building without local-submodule-visibility breaks we won't revert other commits and we won't loose LLDB's/Clang's test run
information.
Reviewers: aprantl, bruno, Bigcheese
Reviewed By: Bigcheese
Subscribers: abidh, dexonsmith, JDevlieghere, lldb-commits, mgorny, llvm-commits
Tags: #llvm, #lldb
Differential Revision: https://reviews.llvm.org/D74892
This is primarily motivated by the desire to move from Python2 to
Python3. `PYTHON_EXECUTABLE` is ambiguous. This explicitly identifies
the python interpreter in use. Since the LLVM build seems to be able to
completed successfully with python3, use that across the build. The old
path aliases `PYTHON_EXECUTABLE` to be treated as Python3.
Summary:
Piggy-back off of TypeSize's STRICT_FIXED_SIZE_VECTORS flag and:
- if it is defined, assert that the vector is not scalable
- if it is not defined, complain if the vector is scalable
Reviewers: efriedma, sdesmalen, c-rhodes
Reviewed By: sdesmalen
Subscribers: hiraditya, mgorny, tschuett, rkruppe, psnobl, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D78576
As discussed in http://lists.llvm.org/pipermail/llvm-dev/2020-March/140349.html,
the minimum version of CMake required to build LLVM will be upgraded to
3.13.4 right after we create the release branch for LLVM 11.0.0.
As part of this effort, this commit adds a warning to give a heads up
to folks regarding the upcoming upgrade. This should allow users to
upgrade their CMake in advance so that the upgrade can sail right
through when the time comes.
Differential Revision: https://reviews.llvm.org/D77740
Summary: This patch is some minor prep work for merging the flang(f18) project into the monorepo. This patch adds "flang" as a supported target for the LLVM_ENABLE_PROJECTS option.
Reviewers: fhahn, tstellar, jdoerfert, beanz, DavidTruby
Reviewed By: DavidTruby
Subscribers: hfinkel, DavidTruby, aartbik, mgorny, llvm-commits
Tags: #flang, #llvm
Differential Revision: https://reviews.llvm.org/D72416
Make the install-llvm-libraries-stripped and install-clang-libraries-stripped
targets depend on the individual library stripped install targets, so
that they actually install the libraries.
Summary:
Related to D75672, this patch adds EVT::isFixedLengthVector to determine
if the underlying vector type is of fixed length.
An assert is introduced in EVT::getVectorNumElements that triggers for
types that aren't fixed length. This is currently guarded by a flag
added D75297 that is off by default and has been renamed to the more
generic ENABLE_STRICT_FIXED_SIZE_VECTORS.
Ideally we want to get rid of getVectorNumElements but a quick grep
shows there are >350 uses in lib/CodeGen and 75 in lib/Target/AArch64
alone. All of these probably aren't EVT::getVectorNumElements (some may
be the MVT equivalent), but there are many places to fixup and having
the assert on by default would make the SVE upstreaming effort
difficult.
Reviewers: sdesmalen, efriedma, ctetreau, huntergr, rengolin
Reviewed By: efriedma
Subscribers: mgorny, kristof.beyls, hiraditya, danielkiss, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D76376
This patch removes compiler runtime assertions that ensure the implicit
conversion are only guaranteed to work for fixed-width vectors.
With the assert it would be impossible to get _anything_ to build until
the
entire codebase has been upgraded, even when the indiscriminate uses of
the size as uint64_t would work fine for both scalable and fixed-width
types.
This issue will need to be addressed differently, with build-time errors
rather than assertion failures, but that effort falls beyond the scope
of this patch.
Returning the scalable size and avoiding the assert in getFixedSize()
is a temporary stop-gap in order to use LLVM for compiling and using
the SVE ACLE intrinsics.
Reviewers: efriedma, huntergr, rovka, ctetreau, rengolin
Reviewed By: efriedma
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D75297
Summary:
Add FORCE_ON option to LLVM_ENABLE_ZLIB, which causes a configuration
error if zlib is not found.
Similar to https://reviews.llvm.org/D40050.
Reviewers: hans, thakis, rnk
Subscribers: mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D76110
This was initially committed and promptly reverted in 9059056e27
after a MSan failure was found by the sanitizer bots.
These have since been fixed.
Summary:
This patch makes the AVR backend an official target of LLVM, serving
as a request for comments for moving the AVR backend out of
experimental.
A future patch will move the LLVM AVR buildbot (llvm-avr-linux) from the
staging buildmaster to the production buildmaster, so error emails will
start to go out.
Summary of the backend
----------------------
- 16-bit little endian
- AsmParser based assembly parser
- uses the MC library for generating AVR ELFs
- most logic driven from standard TableGen-erated tables like other
backends
- passes all of the test suite under `check-all`, including generic
CodeGen and DebugInfo tests
- Used in two frontends
- Limited, but functional support for DebugInfo and LLVM DWARF dumping
- Binary compatible with AVR-GCC and avr-{libc,libgcc} for the most part
- Cannot lower 32-bit shifts due to a bug, can lower shifts larger or
smaller
- Supports assembly/MC for all the entire AVR ISA, generally generates poorly
optimized machine instructions, with most focus thus far on correctness
I've added reviewers and subscribers from previous patches where backends were made official,
and those who participated in the recent thread on llvm-dev, please add anybody I've missed.
The most recent discussion on this topic can be found in the llvm-dev thread [Moving the AVR backend out of experimental](https://lists.llvm.org/pipermail/llvm-dev/2020-February/139158.html)
Reviewers: chandlerc, lattner, rengolin, tstellar, arsenm, thakis, simoll, asb
Reviewed By: rengolin, thakis
Subscribers: CryZe, wdng, mgorny, aprantl, Jim, hans, aykevl, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D75099
Summary:
This patch makes the AVR backend an official target of LLVM, serving
as a request for comments for moving the AVR backend out of
experimental.
A future patch will move the LLVM AVR buildbot (llvm-avr-linux) from the
staging buildmaster to the production buildmaster, so error emails will
start to go out.
Summary of the backend
----------------------
- 16-bit little endian
- AsmParser based assembly parser
- uses the MC library for generating AVR ELFs
- most logic driven from standard TableGen-erated tables like other
backends
- passes all of the test suite under `check-all`, including generic
CodeGen and DebugInfo tests
- Used in two frontends
- Limited, but functional support for DebugInfo and LLVM DWARF dumping
- Binary compatible with AVR-GCC and avr-{libc,libgcc} for the most part
- Cannot lower 32-bit shifts due to a bug, can lower shifts larger or
smaller
- Supports assembly/MC for all the entire AVR ISA, generally generates poorly
optimized machine instructions, with most focus thus far on correctness
I've added reviewers and subscribers from previous patches where backends were made official,
and those who participated in the recent thread on llvm-dev, please add anybody I've missed.
The most recent discussion on this topic can be found in the llvm-dev thread [Moving the AVR backend out of experimental](https://lists.llvm.org/pipermail/llvm-dev/2020-February/139158.html)
Reviewers: chandlerc, lattner, rengolin, tstellar, arsenm, thakis, simoll, asb
Reviewed By: rengolin, thakis
Subscribers: CryZe, wdng, mgorny, aprantl, Jim, hans, aykevl, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D75099
and follow-ups:
a2ca1c2d "build: disable zlib by default on Windows"
2181bf40 "[CMake] Link against ZLIB::ZLIB"
1079c68a "Attempt to fix ZLIB CMake logic on Windows"
This changed the output of llvm-config --system-libs, and more
importantly it broke stand-alone builds. Instead of piling on more fix
attempts, let's revert this to reduce the risk of more breakages.
Summary:
AIX supports both 32-bit and 64-bit environments (with 32-bit being the default). This patch improves support for building LLVM on AIX in both 32-bit and 64-bit mode.
- Change host detection to return correct 32/64-bit triple as config_guess does not return the correct version on 64-bit. This can confuse JIT tests and other things that care about what the host triple is.
- Remove manual setting of 64-bit flags on AIX. AIX provides OBJECT_MODE environment variable to enable the user to obtain a 64-bit development environment. CMake will properly set these flags provided the user sets the correct OBJECT_MODE before configuring and setting them manually will interfere with 32-bit builds.
- Don't present the LLVM_BUILD_32_BITS option on AIX, users should use OBJECT_MODE when running CMake instead.
Reviewers: hubert.reinterpretcast, DiggerLin, stevewan
Reviewed By: DiggerLin, stevewan
Subscribers: mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D74256
Use a dedicated cmake file to store the extension configured within LLVM. That
way, a standalone build of clang can load this cmake file and get all the
configured standalone extensions.
This patch is related to https://reviews.llvm.org/D74602
Differential Revision: https://reviews.llvm.org/D74757
zlib usage on Windows has caused issues in the past. Furthermore, the
GNUWin32 library can be detected and used although the headers are not
available. Require Windows to explicitly opt in.
Rather than handling zlib handling manually, use `find_package` from CMake
to find zlib properly. Use this to normalize the `LLVM_ENABLE_ZLIB`,
`HAVE_ZLIB`, `HAVE_ZLIB_H`. Furthermore, require zlib if `LLVM_ENABLE_ZLIB` is
set to `YES`, which requires the distributor to explicitly select whether
zlib is enabled or not. This simplifies the CMake handling and usage in
the rest of the tooling.
This restores 68a235d07f,
e6c7ed6d21. The problem with the windows
bot is a need for clearing the cache.
There's quite a lot of references to Polly in the LLVM CMake codebase. However
the registration pattern used by Polly could be useful to other external
projects: thanks to that mechanism it would be possible to develop LLVM
extension without touching the LLVM code base.
This patch has two effects:
1. Remove all code specific to Polly in the llvm/clang codebase, replaicing it
with a generic mechanism
2. Provide a generic mechanism to register compiler extensions.
A compiler extension is similar to a pass plugin, with the notable difference
that the compiler extension can be configured to be built dynamically (like
plugins) or statically (like regular passes).
As a result, people willing to add extra passes to clang/opt can do it using a
separate code repo, but still have their pass be linked in clang/opt as built-in
passes.
Differential Revision: https://reviews.llvm.org/D61446
Fangrui Song