This reverts commit e7568b68da and relands
c6f7b720ec.
The culprit was: missed that libc also had a dependency on one of the
copies of `google-benchmark`
Also opportunistically fixed indentation from prev. change.
Differential Revision: https://reviews.llvm.org/D112012
under third-party
This change:
- moves the libcxx copy of `google/benchmark` to
`third-party/benchmkark`
- points the 2 uses of the library (libcxx and llvm/utils) to this copy
We picked the licxx copy because it is the most up to date.
Differential Revision: https://reviews.llvm.org/D112012
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
[NFC] This patch fixes URLs containing "master". Old URLs were either broken or
redirecting to the new URL.
Reviewed By: #libc, ldionne, mehdi_amini
Differential Revision: https://reviews.llvm.org/D113186
Default to preferring forward slashes when built for MinGW, as
many usecases, when e.g. Clang is used as a drop-in replacement
for GCC, requires the compiler to output paths with forward slashes.
Not all tests pass yet, if configuring to prefer forward slashes though.
Differential Revision: https://reviews.llvm.org/D112787
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
This updates the LLVM wide documentation for building LLVM and the runtimes
and adds a CMake warning when folks specify libcxx, libcxxabi or libunwind
in LLVM_ENABLE_PROJECTS, pointing them to the updated instructions for
building the runtimes.
Differential Revision: https://reviews.llvm.org/D112724
The tests that exercise the 'release' mode, where the model is AOT-ed,
check the output has certain properties, to validate that, indeed, a
different policy from the default one was exercised. For determinism, we
can't reliably check that output for an arbitrary learned policy, since
it could be that policy happens to mimic the default one in that
particular case.
This patch adds a requirement that those tests run only when the model
is autogenerated (e.g. on build bots).
Differential Revision: https://reviews.llvm.org/D111747
Due to the way detecting the hard float ABI is currently
handled, clang fails to find the per target dir.
I am working to fix this but in the meantime disable it by
default on Arm Linux.
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
Mircea Trofin