This reverts commit fe82a3da36196157c0caa1ef2505186782f750d1.
This broke LLDB on MacOS due to a missing symbol during linking.
The fix has been applied in c6c08eee37bada190bd1aa4593c88a5e2c8cdaac.
Original commit message:
The terminfo dependency introduces a significant nonhermeticity into the
build. It doesn't respect `--no-undefined-version` meaning that it's not
a dependency that can be built with Clang 17+. This forces maintainers
of source-based distributions to implement patches or ignore linker
errors.
Remove it to reduce the closure size and improve portability of
LLVM-based tools. Users can still use command line arguments to toggle
color support expliticly.
Fixes#75490Closes#53294#23355
The terminfo dependency introduces a significant nonhermeticity into the
build. It doesn't respect `--no-undefined-version` meaning that it's not
a dependency that can be built with Clang 17+. This forces maintainers
of source-based distributions to implement patches or ignore linker
errors.
Remove it to reduce the closure size and improve portability of
LLVM-based tools. Users can still use command line arguments to toggle
color support expliticly.
Fixes#75490Closes#53294#23355
This introduces a new file, RISCVISAUtils.cpp and moves the rest of
RISCVISAInfo to the TargetParser library.
This will allow us to generate part of RISCVISAInfo.cpp using tablegen.
Defines a subset of attributes and emits them to a section called
.hexagon.attributes.
The current attributes recorded are the attributes needed by
llvm-objdump to automatically determine target features and eliminate
the need to manually pass features.
Include the `LLVM_REPOSITORY` and `LLVM_REVISION` in the version output
of tools using `cl::PrintVersionMessage()` such as dwarfdump and
dsymutil.
Before:
```
$ llvm-dwarfdump --version
LLVM (http://llvm.org/):
LLVM version 19.0.0git
Optimized build with assertions.
```
After:
```
$ llvm-dwarfdump --version
LLVM (http://llvm.org/):
LLVM version 19.0.0git (git@github.com:llvm/llvm-project.git 8467457afc61d70e881c9817ace26356ef757733)
Optimized build with assertions.
```
rdar://121526866
This provides a simple way to implement exponential backoff using a do
while loop.
Usage example (also see the change to LockFileManager.cpp):
```
ExponentialBackoff Backoff(10s);
do {
if (tryToDoSomething())
return ItWorked;
} while (Backoff.waitForNextAttempt());
return Timeout;
```
Abstracting this out of `LockFileManager` as the module build daemon
will need it.
Haiku and Solaris need some additional libraries after the commit
c0d5d36dda04cdd409aabc015da0beb810842fcd
Otherwise fails to link a whole bunch of the tools and other binaries
with undefined symbols with accept() and connect().
I did a static and dynamic build on illumos and a dynamic build on
Haiku.
```
-DLLVM_ENABLE_PROJECTS='clang;clang-tools-extra;lld;mlir'
```
and on illumos
```
-DLLVM_ENABLE_RUNTIMES='openmp'
```
This originally used the spelling Ws2_32 when added in
a5ffabce98a4b2e9d69009fa3e60f2b154100860, but was changed to WS2_32
in 042a2e8932984e6c9f2017cbabb5bc66ad5419ce with the intent to
use the canonical spelling from WinSDK, in order to aid cross
compilation from case sensitive file systems with WinSDK.
However, the WinSDK itself is self-inconsistent with respect
to file name cases. Headers refer to each other with many different
casings, so the original, out of the box casing doesn't work
on case sensitive file systems. Import libraries like these
use a variety of casings (some use all lowercase, some use
CamelCase, some all uppercase, and the suffix is either .lib,
.Lib or .LIB).
In order to use the WinSDK on a case sensitive file system, these
case issues has to be worked around somehow. Either by lowercasing
all files (and the #includes within them, and potentially keeping
symlinks with their original casing), or by setting up a Clang
case insensitive VFS overlay. LLVM's llvm/cmake/platforms/WinMsvc.cmake
sets up such a VFS overlay. For the linker, it creates a directory
with lowercase symlinks.
Therefore, the canonical way of handling these casing issues on
case sensitive file systems is to consistently use lowercase. That
is also what MinGW toolchains use.
As an example, the same list of system_libs refers to advapi32,
even if the actual file on disk in WinSDK is AdvAPI32.Lib.
Likewise, other in-tree build systems that picked up this change
for ws2_32 made it all lowercase, in
b07aaf8d3bde911638b0370037204898c3c2deb7 and
d22dad9f768fef376546053952f0b49b23bebfde. This also matches other
existing references to ws2_32 in e.g.
lldb/source/Plugins/Process/Windows/Common/CMakeLists.txt and
lldb/source/Utility/CMakeLists.txt.
The file name is WS2_32.Lib in all the Windows SDK versions I looked at.
You can get away with the incorrect casing on a case-insensitive file
system but it can matter for cross-compilation.
The threading library does not recognize AIX and always returns `-1` for
number of physical cores on AIX. This PR teaches the library to
recognize AIX and obtain the correct value for the number of physical
cores.
With the new behaviour, the /MD or similar options aren't added to
e.g. CMAKE_CXX_FLAGS_RELEASE, but are added separately by CMake.
They can be changed by the cmake variable
CMAKE_MSVC_RUNTIME_LIBRARY or with the target property
MSVC_RUNTIME_LIBRARY.
LLVM has had its own custom CMake flags, e.g. LLVM_USE_CRT_RELEASE,
which affects which CRT is used for release mode builds. Deprecate
these and direct users to use CMAKE_MSVC_RUNTIME_LIBRARY directly
instead (and do a best effort attempt at setting CMAKE_MSVC_RUNTIME_LIBRARY
based on the existing LLVM_USE_CRT_ flags). This only handles the
simple cases, it doesn't handle multi-config generators with
different LLVM_USE_CRT_* variables for different configs though,
but that's probably fine - we should move over to the new upstream
CMake mechanism anyway, and push users towards that.
Change code in compiler-rt, that previously tried to override the
CRT choice to /MT, to set CMAKE_MSVC_RUNTIME_LIBRARY instead of
meddling in the old variables.
This resolves the policy issue in
https://github.com/llvm/llvm-project/issues/63286, and should
handle the issues that were observed originally when the
minimum CMake version was bumped, in
https://github.com/llvm/llvm-project/issues/62719 and
https://github.com/llvm/llvm-project/issues/62739.
Differential Revision: https://reviews.llvm.org/D155233
`TrigramIndex` was added back in https://reviews.llvm.org/D27188 as an optimization to make `SpecialCaseList::match()` faster. I've found that `TrigramIndex` actually makes the function slower and it has no functional use, so we can remove it.
I grabbed the list of queries passed to `SpecialCaseList::match()` on a random very large file (`AArch64ISelLowering.cpp`) and measured the runtime to call `match()` on all of them with [this line](8e1f820bb4/llvm/lib/Support/SpecialCaseList.cpp (L64)) disabled and then enabled.
```
$ hyperfine --warmup 3 'GTEST_FILTER="SpecialCaseListTest.Large" USE_TRIGRAMS=1 build/unittests/Support/SupportTests' 'GTEST_FILTER="SpecialCaseListTest.Large" USE_TRIGRAMS=0 build/unittests/Support/SupportTests'
Benchmark 1: GTEST_FILTER="SpecialCaseListTest.Large" USE_TRIGRAMS=1 build/unittests/Support/SupportTests
Time (mean ± σ): 575.9 ms ± 20.3 ms [User: 573.1 ms, System: 2.7 ms]
Range (min … max): 555.5 ms … 620.0 ms 10 runs
Benchmark 2: GTEST_FILTER="SpecialCaseListTest.Large" USE_TRIGRAMS=0 build/unittests/Support/SupportTests
Time (mean ± σ): 283.4 ms ± 6.7 ms [User: 280.3 ms, System: 3.0 ms]
Range (min … max): 277.0 ms … 294.9 ms 10 runs
Summary
'GTEST_FILTER="SpecialCaseListTest.Large" USE_TRIGRAMS=0 build/unittests/Support/SupportTests' ran
2.03 ± 0.09 times faster than 'GTEST_FILTER="SpecialCaseListTest.Large" USE_TRIGRAMS=1 build/unittests/Support/SupportTests'
```
Using `perf` I found that most of the runtime in `TrigramIndex::isDefinitelyOut()` comes from a division operation that seems to come from `std::unordered_map`: 8e1f820bb4/llvm/include/llvm/Support/TrigramIndex.h (L62)
Removing `TrigramIndex` will make it easier to potentially switch to using `GlobPattern` instead of a full regex for `SpecialCaseList`. See discussion in https://reviews.llvm.org/D152762 for details.
Reviewed By: MaskRay, #sanitizers, vitalybuka
Differential Revision: https://reviews.llvm.org/D153171
In [0] we described an algorithm called //BalancedPartitioning// (bp) to consume function traces [1] and compute a function order that reduces the number of page faults during startup.
This patch adds the `order` command to the `llvm-profdata` tool which uses bp to output a function order that can be passed to the linker via `--symbol-ordering-file=`.
Special thanks to Sergey Pupyrev and Julian Mestre for designing this balanced partitioning algorithm.
[0] https://discourse.llvm.org/t/rfc-temporal-profiling-extension-for-irpgo/68068
[1] https://reviews.llvm.org/D147287
Reviewed By: spupyrev
Differential Revision: https://reviews.llvm.org/D147812
This is rework of;
- D30046 (LLT)
Since I have introduced `llvm-min-tblgen` as D146352, `llvm-tblgen`
may depend on `CodeGen`.
`LowLevlType.h` originally belonged to `CodeGen`. Almost all userse are
still under `CodeGen` or `Target`. I think `CodeGen` is the right place
to put `LowLevelType.h`.
`MachineValueType.h` may be moved as well. (later, D149024)
I have made many modules depend on `CodeGen`. It is consistent but
inefficient. It will be split out later, D148769
Besides, I had to isolate MVT and LLT in modmap, since
`llvm::PredicateInfo` clashes between `TableGen/CodeGenSchedule.h`
and `Transforms/Utils/PredicateInfo.h`.
(I think better to introduce namespace llvm::TableGen)
Depends on D145937, D146352, and D148768.
Differential Revision: https://reviews.llvm.org/D148767
As mentioned on https://discourse.llvm.org/t/issues-in-llvm-tblgen-high-parallelized-build/68037, ItaniumManglingCanonicalizer is often slow to build, resulting in a bottleneck for distributed builds while waiting for LLVMSupport to complete.
SymbolRemappingReader is the only current user of ItaniumManglingCanonicalizer, and this is only used by ProfileData and llvm-cxxmap - so I propose we move both files into the ProfileData library.
Differential Revision: https://reviews.llvm.org/D143318
This patch fixes#60307 issue. The 8bb4451 introduces the possibility
to unite overlapped or adjacent address ranges to keep address ranges
in an unambiguous state. The AddressRangesMap is used to normalize
address ranges. The AddressRangesMap keeps address ranges and the value
of the relocated address. For intersected range, it creates a united
range that keeps the last inserted mapping value. The same for adjusted ranges.
While it is OK to use the last inserted mapping value for intersected ranges
(as there is no way how to resolve ambiguity) It is not OK to use the
last inserted value for adjacent address ranges. Currently, two following
address ranges are united into a single one:
{0,24,17e685c} {24,d8,55afe20} -> {0,d8,55afe20}
To avoid the problem, the AddressRangesMap should not unite adjacent address ranges
with different relocated addresses. Instead, it should leave adjacent address ranges
as separate ranges. So, the ranges should look like this:
{0,24,17e685c} {24,d8,55afe20}
Differential Revision: https://reviews.llvm.org/D142936
Make the access to profile data going through virtual file system so the
inputs can be remapped. In the context of the caching, it can make sure
we capture the inputs and provided an immutable input as profile data.
Reviewed By: akyrtzi, benlangmuir
Differential Revision: https://reviews.llvm.org/D139052
This reverts commit c5abe893120b115907376359a5809229a9f9608a.
This reverts commit a033dbbe5c43247b60869b008e67ed86ed230eaa.
This broke the build with -DLLVM_LINK_LLVM_DYLIB=ON. Reverting while I
investigate.
Every Clang instance uses an internal FileSystemStatCache to avoid
stating the same content multiple times. However, different instances
of Clang will contend for filesystem access for their initial stats
during HeaderSearch or module validation.
On some workloads, the time spent in the kernel in these concurrent
stat calls has been measured to be over 20% of the overall compilation
time. This is extremly wassteful when most of the stat calls target
mostly immutable content like a SDK.
This commit introduces a new tool `clang-stat-cache` able to generate
an OnDiskHashmap containing the stat data for a given filesystem
hierarchy.
The driver part of this has been modeled after -ivfsoverlay given
the similarities with what it influences. It introduces a new
-ivfsstatcache driver option to instruct Clang to use a stat cache
generated by `clang-stat-cache`. These stat caches are inserted at
the bottom of the VFS stack (right above the real filesystem).
Differential Revision: https://reviews.llvm.org/D136651
This has been obsoleted by C++ thread_local for a long time.
As far as I know, Xcode was the last supported toolchain to add
support for C++ thread_local in 2016.
As a precaution, use LLVM_THREAD_LOCAL which provides even greater
backwards compatibility, allowing this to function even pre-C++11
versions of GCC.
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D141349
This has been obsoleted by C++ thread_local for a long time.
As far as I know, Xcode was the last supported toolchain to add
support for C++ thread_local in 2016.
As a precaution, use LLVM_THREAD_LOCAL which provides even greater
backwards compatibility, allowing this to function even pre-C++11
versions of GCC.
Reviewed By: majnemer
Differential Revision: https://reviews.llvm.org/D141347
So that there is no cyclic dependency if we want to use it in
tablegen.
Reviewed By: fpetrogalli
Differential Revision: https://reviews.llvm.org/D140529
This is a fairly large changeset, but it can be broken into a few
pieces:
- `llvm/Support/*TargetParser*` are all moved from the LLVM Support
component into a new LLVM Component called "TargetParser". This
potentially enables using tablegen to maintain this information, as
is shown in https://reviews.llvm.org/D137517. This cannot currently
be done, as llvm-tblgen relies on LLVM's Support component.
- This also moves two files from Support which use and depend on
information in the TargetParser:
- `llvm/Support/Host.{h,cpp}` which contains functions for inspecting
the current Host machine for info about it, primarily to support
getting the host triple, but also for `-mcpu=native` support in e.g.
Clang. This is fairly tightly intertwined with the information in
`X86TargetParser.h`, so keeping them in the same component makes
sense.
- `llvm/ADT/Triple.h` and `llvm/Support/Triple.cpp`, which contains
the target triple parser and representation. This is very intertwined
with the Arm target parser, because the arm architecture version
appears in canonical triples on arm platforms.
- I moved the relevant unittests to their own directory.
And so, we end up with a single component that has all the information
about the following, which to me seems like a unified component:
- Triples that LLVM Knows about
- Architecture names and CPUs that LLVM knows about
- CPU detection logic for LLVM
Given this, I have also moved `RISCVISAInfo.h` into this component, as
it seems to me to be part of that same set of functionality.
If you get link errors in your components after this patch, you likely
need to add TargetParser into LLVM_LINK_COMPONENTS in CMake.
Differential Revision: https://reviews.llvm.org/D137838
AArch64TargetParser reuses data structures and some data from ARMTargetParser,
which causes more problems than it solves. This change separates them.
Code which is common to ARM and AArch64 is moved to ARMTargetParserCommon
which both ARMTargetParser and AArch64TargetParser use.
Some of the information in AArch64TargetParser.def was unused or nonsensical
(CPU_ATTR, ARCH_ATTR, ARCH_FPU) because it reused data strutures from
ARMTargetParser where some of these make sense. These are removed.
Differential Revision: https://reviews.llvm.org/D137924
* Set LLVM_ATOMIC_LIB to keep track of when we need to link against libatomic.
* Add detection of mold linker which is required for this.
* Use --as-needed when linking against libatomic as a bonus. On some platforms,
libatomic may be required only sometimes.
Bug: https://bugs.gentoo.org/832675
Thanks-to: Arfrever Frehtes Taifersar Arahesis <Arfrever@Apache.Org>
Tested-by: erhard_f@mailbox.org <erhard_f@mailbox.org>
Differential Revision: https://reviews.llvm.org/D136280
This change modifies the implementation of the format() function
so that vendor forks committed to building with compilers that
support __attribute__((format)) on non-variadic functions can
check the format() function with it.
rdar://84571523
This change modifies the implementation of the format() function
so that vendor forks committed to building with compilers that
support __attribute__((format)) on non-variadic functions can
check the format() function with it.
Reviewed By: ahatanak
Differential Revision: https://reviews.llvm.org/D132413
rdar://84571523
add LLVM_PREFER_STATIC_ZSTD (default TRUE) cmake config flag
(compression test seems to fail for shared zstd on windows, note that zstd multithread is by default disabled in the static build so it may be a hidden variable)
propagate variable zstd_DIR in LLVMConfig.cmake.in
fix llvm-config CMakeLists.txt behavior for absolute libs windows
get zstd lib name
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D132870
While working on D118450 <https://reviews.llvm.org/D118450>, I noticed that
`sys::getHostCPUName` lacks SPARC support.
This patch implements it. The code is taken from/inspired by GCC's
`gcc/config/sparc/driver-sparc.cc`. There's one caveat: since LLVM, unlike
GCC, doesn't support the SPARC-M7, -S7, and -M8 CPUs, I map all those to
the latest supported one (UltraSparc T4/`niagara4`).
Tested on `sparcv9-sun-solaris2.11` and `sparc64-unknown-linux-gnu` by
running `savcov --version` on
- Netra SPARC S7-2 (SPARC-S7, Solaris 11.4)
- SPARC T5-2 (SPARC T5, Solaris 11.4)
- SPARC Enterprise T5220 (UltraSPARC T2, Solaris 11.3)
- SPARC T5 (UltraSPARC T5, Debian sid)
- SPARC T3 (UltraSPARC T3, Debian sid)
- SPARC Enterprise T5220 (Debian sid)
Differential Revision: https://reviews.llvm.org/D130272
- 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`
- debian users should install libzstd when using `LLVM_ENABLE_ZSTD=FORCE_ON` from source due to this bug https://bugs.launchpad.net/ubuntu/+source/libzstd/+bug/1941956
Reviewed By: leonardchan, MaskRay
Differential Revision: https://reviews.llvm.org/D128465
This reverts commit d449c600767284486615f3b79601ced15a00af61.
Breaks macOS builds with this:
llvm/lib/Support/Compression.cpp:24:10: fatal error: 'zstd.h' file not found
- 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 `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
