| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Created using spr 1.3.4
[skip ci]
|
|
This patch upstreams some of the MLGO utilities, particularly the corpus
extraction tooling, into LLVM proper. The motivation for this patch is
available in the RFC.
https://discourse.llvm.org/t/rfc-upstreaming-elements-of-the-mlgo-tooling/74939
|
|
(#78653)"
This reverts commit 82bc33ea3f1a539be50ed46919dc53fc6b685da9.
Accidentally pushed unrelated changes.
|
|
Fix the bug where merge-fdata unconditionally outputs boltedcollection
line, regardless of whether input files have it set.
Test Plan:
Added bolt/test/X86/merge-fdata-nobat-mode.test which fails without this
fix.
|
|
reporting. (#78210)
This allows release teams to customize the bug report url for lldb. It
also removes unnecessary constructions of
`llvm::PrettyStackTraceProgram` as it's already constructed inside
`llvm::InitLLVM`.
|
|
Re-apply 7f215b1380da49dccbf57da3040a40d25ed898f4, which was reverted in
a9e3d232a520a17f098d4dc872c9591c565e7d36.
The orginal commit uncovered a bug that was fixed by
4701f776d0f22dc0ff80a7d33ef3ae031eac9c2f.
Fixes #58680
|
|
This fixes the macro syntax
|
|
This change extend the CMake files with the necessary additions to build LLVM for z/OS.
|
|
This caused some runtimes builds to fail with:
error: unknown target 'runtimes-test-depends'
See comments on the PR.
> The test-depends target contained all the dependencies needed to run the
> runtimes tests, but it was never added as a dependency of check-all.
> This caused some of the tsan tests to fail, since the custom libcxx
> build the tests were looking for was never built. Besides the tsan
> failures, this fixes all the other test failures I was seeing with:
> cmake -G Ninja -B release-build -S llvm \
> -DCMAKE_POSITION_INDEPENDENT_CODE=ON \
> -DCMAKE_BUILD_TYPE=Release \
> -DLLVM_ENABLE_ASSERTIONS=OFF \
> -DLLVM_ENABLE_PROJECTS="clang;lld" \
> -DLLVM_ENABLE_RUNTIMES="libcxx;libcxxabi;libunwind;compiler-rt"
>
> This is the same configuration the test-release.sh script uses, so I'm
> hoping this will also fix all the test failures we've been seeing when
> building the releases.
>
> Fixes #58680
This reverts commit 7f215b1380da49dccbf57da3040a40d25ed898f4.
|
|
The test-depends target contained all the dependencies needed to run the
runtimes tests, but it was never added as a dependency of check-all.
This caused some of the tsan tests to fail, since the custom libcxx
build the tests were looking for was never built. Besides the tsan
failures, this fixes all the other test failures I was seeing with:
cmake -G Ninja -B release-build -S llvm \
-DCMAKE_POSITION_INDEPENDENT_CODE=ON \
-DCMAKE_BUILD_TYPE=Release \
-DLLVM_ENABLE_ASSERTIONS=OFF \
-DLLVM_ENABLE_PROJECTS="clang;lld" \
-DLLVM_ENABLE_RUNTIMES="libcxx;libcxxabi;libunwind;compiler-rt"
This is the same configuration the test-release.sh script uses, so I'm
hoping this will also fix all the test failures we've been seeing when
building the releases.
Fixes #58680
|
|
This patch makes it so that specifying an invalid value for
CMAKE_BUILD_TYPE is a fatal error. Having this simply as a warning has
caused me (and probably others) a decent amount of headache. The check
was present before, but was proposed to be modified to a warning in
https://github.com/llvm/llvm-project/issues/60975 and changed to a
warning in c75dbeda15c10424910ddc83a9ff7669776c19ac. This patch
reenables that behavior to hopefully reduce frustration for people
building LLVM in the common case while still allowing for alternative
build types to be setup without needing to perform source modification
through the addition of a CMake flag.
|
|
These macro can help guarding some tests and other section of code
which rely on detecting if a particular target is available. This
is common the MLIR codegeneration for GPU targets for example.
|
|
LLVM_EXPERIMENTAL_TARGETS_TO_BUILD (#70885)
Targeting X86 while building LLVM with the Android NDK, currently fails
with "The target `X86' is not a core tier target. It may be experimental,
if so it must be passed via LLVM_EXPERIMENTAL_TARGETS_TO_BUILD."
This is happening because the Android NDK defines a variable named X86,
which will lead to a "fun" CMake feature. For further details reference
[this post](https://discourse.llvm.org/t/the-target-x86-is-not-a-core-tier-target/73784).
To fix this, the LLVM_TARGETS_TO_BUILD need to be escaped while checking
agains LLVM_ALL_TARGETS and LLVM_EXPERIMENTAL_TARGETS_TO_BUILD.
|
|
This patch add CMake option "LLVM_GTEST_RUN_UNDER" to LLVM unittest
configuration. When specified, LLVM unittest will be run under the
wrapper program specified by this option. This feature can simplify the
setup to run LLVM unittest on a target platform that is different than
host.
|
|
...behind an experimental CMAKE option that's off by default.
This patch adds a new ilist-iterator-like class that can carry two extra bits
as well as the usual node pointer. This is part of the project to remove
debug-intrinsics from LLVM: see the rationale here [0], they're needed to
signal whether a "position" in a BasicBlock includes any debug-info before or
after the iterator.
This entirely duplicates ilist_iterator, attempting re-use showed it to be a
false economy. It's enable-able through the existing ilist_node options
interface, hence a few sites where the instruction-list type needs to be
updated. The actual main feature, the extra bits in the class, aren't part of
the class unless the cmake flag is given: this is because there's a
compile-time cost associated with it, and I'd like to get everything in-tree
but off-by-default so that we can do proper comparisons.
Nothing actually makes use of this yet, but will do soon, see the Phab patch
stack.
[0] https://discourse.llvm.org/t/rfc-instruction-api-changes-needed-to-eliminate-debug-intrinsics-from-ir/68939
Differential Revision: https://reviews.llvm.org/D153777
|
|
runtime LLVM integration"
This reverts commit 6403287eff71a3d6f6c862346d6ed3f0f000eb70.
This is failing on all but 1 of Linaro's flang builders.
CMake Error at /home/tcwg-buildbot/worker/clang-aarch64-full-2stage/llvm/flang-rt/unittests/CMakeLists.txt:37 (message):
Target llvm_gtest not found.
|
|
When custom install names and rpaths setups are used they may not
work in the build tree as-is (namely when using absolute paths for
install names in order to avoid rpath juggling in downstream projects).
Add a flag for opting out of this behaviour.
See: https://reviews.llvm.org/D42463
|
|
LLVM integration
See discourse thread https://discourse.llvm.org/t/rfc-support-cmake-option-to-control-link-type-built-for-flang-runtime-libraries/71602/18 for full details.
Flang-rt is the new library target for the flang runtime libraries. It builds the Flang-rt library (which contains the sources of FortranRuntime and FortranDecimal) and the Fortran_main library. See documentation in this patch for detailed description (flang-rt/docs/GettingStarted.md).
This patch aims to:
- integrate Flang's runtime into existing llvm infrasturcture so that Flang's runtime can be built similarly to other runtimes via the runtimes target or via the llvm target as an enabled runtime
- decouple the FortranDecimal library sources that were used by both compiler and runtime so that different build configurations can be applied for compiler vs runtime
- add support for running flang-rt testsuites, which were created by migrating relevant tests from `flang/test` and `flang/unittest` to `flang-rt/test` and `flang-rt/unittest`, using a new `check-flang-rt` target.
- provide documentation on how to build and use the new FlangRT runtime
Reviewed By: DanielCChen
Differential Revision: https://reviews.llvm.org/D154869
|
|
This patch adds a LLVM_FORCE_VC_REVISION option to force a custom
VC revision to be included instead of trying to fetch one from a
git command. This is helpful in environments where git is not
available or is non-functional but the vc revision is available
through some other means.
|
|
This module is only used in two places and its logic can be inlined and
simplified.
|
|
Previously you would get this error when passing an experimental target
via LLVM_TARGETS_TO_BUILD:
```
cmake ../llvm-project/llvm -DLLVM_TARGETS_TO_BUILD=M68k -DCMAKE_BU
ILD_TYPE=Release -GNinja
CMake Error at CMakeLists.txt:929 (message):
The target `M68k' is experimental and must be passed via
LLVM_EXPERIMENTAL_TARGETS_TO_BUILD
```
Since M68k is a known experimental target, this is helpful. However,
any made up target name would give you the same error.
```
cmake ../llvm-project/llvm -DLLVM_TARGETS_TO_BUILD=NotATarget -DCMAKE_BUILD_TYPE=Release -GNinja
CMake Error at CMakeLists.txt:929 (message):
The target `NotATarget' is experimental and must be passed via
LLVM_EXPERIMENTAL_TARGETS_TO_BUILD.
```
We know the set of default targets and in tree experimental targets,
so let's be more specific if we know that it is not an in tree experimental
target:
```
CMake Error at CMakeLists.txt:934 (message):
The target `NotATarget' is not a default target. It may be experimental,
if so it must be passed via LLVM_EXPERIMENTAL_TARGETS_TO_BUILD.
Core tier targets:
AArch64;AMDGPU;ARM;AVR;BPF;Hexagon;Lanai;LoongArch;Mips;MSP430;NVPTX;PowerPC;RISCV;Sparc;SystemZ;VE;WebAssembly;X86;XCore
Known experimental targets: ARC;CSKY;DirectX;M68k;SPIRV;Xtensa
```
It "may" be an experimental target because we do allow users to specify
targets that are not in LLVM_ALL_EXPERIMENTAL_TARGETS, and they will work
as long as lib/Target/<target> exists.
Maybe that could be made more strict but it would break a bunch of
forks for not much gain.
The known target names are listed to help users trying to configure
architectures with confusing naming schemes, for example Arm. Which is
variously called ARM/Arm/Armv7/AArch32 across llvm and other software.
Reviewed By: beanz
Differential Revision: https://reviews.llvm.org/D157844
|
|
divided per test case
This patch is the first part of https://llvm.org/OpenProjects.html#llvm_patch_coverage.
We have first define a new variable LLVM_TEST_COVERAGE which when set, pass --per-test-coverage option to
llvm-lit which will help in setting a unique value to LLVM_PROFILE_FILE for each RUN. So for example
coverage data for test case llvm/test/Analysis/AliasSet/memtransfer.ll will be emitted as
build/test/Analysis/AliasSet/memtransfer0.profraw
Reviewed By: hnrklssn
Differential Revision: https://reviews.llvm.org/D154280
|
|
|
|
coverage data, divided per test case"
This reverts commit d8e26bccb3016d255298b7db78fe8bf05dd880b2.
Test case are meant to run only when LLVM_INDIVIDUAL_TEST_COVERAGE is set.
|
|
divided per test case
This patch is the first part of https://llvm.org/OpenProjects.html#llvm_patch_coverage.
We have first define a new variable LLVM_TEST_COVERAGE which when set, pass --emit-coverage option to
llvm-lit which will help in setting a unique value to LLVM_PROFILE_FILE for each RUN. So for example
coverage data for test case llvm/test/Analysis/AliasSet/memtransfer.ll will be emitted as
build/test/Analysis/AliasSet/memtransfer.profraw
Reviewed By: hnrklssn
Differential Revision: https://reviews.llvm.org/D154280
|
|
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
|
|
When set to "all" we will now build all experimental targets. This matches
the behaviour for LLVM_TARGETS_TO_BUILD.
Reviewed By: beanz
Differential Revision: https://reviews.llvm.org/D138433
|
|
CMake older than 3.20.0 is no longer supported.
This removes work-arounds for no longer supported versions.
Reviewed By: kwk
Differential Revision: https://reviews.llvm.org/D152103
|
|
This patch adds in CMake option LLVM_ENABLE_LLVM_LIBC which when set to
true automatically builds LLVM libc in overlay mode and links all
generated executables against the libc overlay. This is intended to
somewhat mirror the LLVM_ENABLE_LIBCXX flag.
Differential Revision: https://reviews.llvm.org/D151013
|
|
This reverts commit d763c6e5e2d0a6b34097aa7dabca31e9aff9b0b6.
Adds the patch by @hans from
https://github.com/llvm/llvm-project/issues/62719
This patch fixes the Windows build.
d763c6e5e2d0a6b34097aa7dabca31e9aff9b0b6 reverted the reviews
D144509 [CMake] Bumps minimum version to 3.20.0.
This partly undoes D137724.
This change has been discussed on discourse
https://discourse.llvm.org/t/rfc-upgrading-llvms-minimum-required-cmake-version/66193
Note this does not remove work-arounds for older CMake versions, that
will be done in followup patches.
D150532 [OpenMP] Compile assembly files as ASM, not C
Since CMake 3.20, CMake explicitly passes "-x c" (or equivalent)
when compiling a file which has been set as having the language
C. This behaviour change only takes place if "cmake_minimum_required"
is set to 3.20 or newer, or if the policy CMP0119 is set to new.
Attempting to compile assembly files with "-x c" fails, however
this is workarounded in many cases, as OpenMP overrides this with
"-x assembler-with-cpp", however this is only added for non-Windows
targets.
Thus, after increasing cmake_minimum_required to 3.20, this breaks
compiling the GNU assembly for Windows targets; the GNU assembly is
used for ARM and AArch64 Windows targets when building with Clang.
This patch unbreaks that.
D150688 [cmake] Set CMP0091 to fix Windows builds after the cmake_minimum_required bump
The build uses other mechanism to select the runtime.
Fixes #62719
Reviewed By: #libc, Mordante
Differential Revision: https://reviews.llvm.org/D151344
|
|
This reverts commit 65429b9af6a2c99d340ab2dcddd41dab201f399c.
Broke several projects, see https://reviews.llvm.org/D144509#4347562 onwards.
Also reverts follow-up commit "[OpenMP] Compile assembly files as ASM, not C"
This reverts commit 4072c8aee4c89c4457f4f30d01dc9bb4dfa52559.
Also reverts fix attempt "[cmake] Set CMP0091 to fix Windows builds after the cmake_minimum_required bump"
This reverts commit 7d47dac5f828efd1d378ba44a97559114f00fb64.
|
|
As for now, 'extract_symbols.py' can use several tools to extract
symbols from object files and libraries and to guess if the target is
32-bit Windows. The tools are being found via PATH, so in most cases,
they are just system tools. This approach has a number of limitations,
in particular:
* System tools may not be able to handle the target format in case of
cross-platform builds,
* They cannot read symbols from LLVM bitcode files, so the staged LTO
build with plugins is not supported,
* The auto-selected tools may be suboptimal (see D113557),
* Support for multiple tools for a single task increases the complexity
of the script code.
The patch proposes using LLVM's own tools to solve these issues.
Specifically, 'llvm-readobj' detects the target platform, and 'llvm-nm'
reads symbols from all supported formats, including bitcode files. The
tools can be built in Release mode for the host platform or overridden
using CMake settings 'LLVM_READOBJ' and 'LLVM_NM' respectively. The
implementation also supports using precompiled tools via
'LLVM_NATIVE_TOOL_DIR'.
Differential Revision: https://reviews.llvm.org/D149119
|
|
The owner of the last two failing buildbots updated CMake.
This reverts commit e8e8707b4aa6e4cc04c0cffb2de01d2de71165fc.
|
|
Unfortunatly not all buildbots are updated.
This reverts commit ffb807ab5375b3f78df198dc5d4302b3b552242f.
|
|
All build bots should be updated now.
This reverts commit 44d38022ab29a3156349602733b3459df5beef93.
|
|
In code we use `#include "llvm/Lib/Header.h"` which is located in
"llvm/include/llvm/Lib/Header.h", so we use "llvm/include/" as a header
search path. We should put modulemaps in the same directory and
shouldn't rely on clang to search in immediate subdirectories.
rdar://106677321
Differential Revision: https://reviews.llvm.org/D148776
|
|
This reverts commit 1ef4c3c859728008cf707cad8d67f45ae5070ae1.
Two buildbots still haven't been updated.
|
|
This reverts commit 92523a35a827539db8557bbc3ecab7f9ea3f6ade.
Reland to see whether CIs are updated.
|
|
This reverts commit a72165e5df59032cdd54dcb18155f2630d73abd1.
Some buildbots have not been updated yet.
|
|
This reverts commit 92523a35a827539db8557bbc3ecab7f9ea3f6ade.
Test whether all CI runners are updated.
|
|
Stand-alone builds need an installed version of gtest in order to run
the unittests.
Reviewed By: mgorny, kwk
Differential Revision: https://reviews.llvm.org/D137890
|
|
Fixes #60975
Reviewed By: bogner
Differential Revision: https://reviews.llvm.org/D144835
|
|
Some build bots have not been updated to the new minimal CMake version.
Reverting for now and ping the buildbot owners.
This reverts commit 44c6b905f8527635e49bb3ea97dea315f92d38ec.
|
|
This partly undoes D137724.
This change has been discussed on discourse
https://discourse.llvm.org/t/rfc-upgrading-llvms-minimum-required-cmake-version/66193
Note this does not remove work-arounds for older CMake versions, that
will be done in followup patches.
Reviewed By: mehdi_amini, MaskRay, ChuanqiXu, to268, thieta, tschuett, phosek, #libunwind, #libc_vendors, #libc, #libc_abi, sivachandra, philnik, zibi
Differential Revision: https://reviews.llvm.org/D144509
|
|
Since GetErrcMessages uses cmake's `try_run` mechanism it's sensitive
to changes to CMAKE_CXX_FLAGS, so we move it into config-ix with the
similar flag-sensitive configuration. This makes it run before
HandleLLVMOptions and avoids issues with LLVM_ENABLE_WERROR and other
configuration that manipulate CMAKE_CXX_FLAGS.
Differential Revision: https://reviews.llvm.org/D144526
|
|
Reviewed By: abhina.sreeskantharajan, zibi
Differential Revision: https://reviews.llvm.org/D143916
|
|
This reverts commit 0fad18c44a14b909a1aa47165021273d4c10a665.
We need bots to be updated first.
|
|
CMake supports CMAKE_CXX_COMPILER_LAUNCHER since CMake 3.4
so this custom CMake logic we had in LLVM can now be removed.
The only downside with this is that we can't set ccache
options from LLVM CMake, but it's arguable that this doesn't
belong in LLVM but should be done in a script calling the
build.
This was discussed in the forums here:
https://discourse.llvm.org/t/tips-for-incremental-building/67289/4?u=tobiashieta
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D143468
|
|
With this change, libc-hdrgen is built like a host build tool like clang and used
to build libc for the target.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D141460
|
|
and BSD
The orginal single folder layout produced libraries in the form:
lib/linux/<libname>-<archname>.a
That archname for Arm depended on whether you had hard or soft float.
This is sometimes shown as "arm" (soft) vs. "armhf" (hard).
If this is set in a triple we do it in the final portion, the ABI.
"gnueabi" for soft float, "gnueabihf" for hard float.
Meaning that the expected triple is:
arm-unknown-linux-gnueabihf
Not this:
armhf-unknown-linux-gnueabihf
For the per target layout I have decided to rely on the ABI portion
of the triple instead of the arch name used for the old layout
(doing that would produce the invalid triple above).
This means that building with triple:
armv8l-unknown-linux-gnueabihf
Will result in libraries in:
lib/arm-unknown-linux-gnueabihf/
And clang will now know to look for "arm" instead of "armv8l".
Meaning that we can share libraries between an armv8 and armv7 build
as we did with the previous layout. In addition to handling spelling
differences e.g. "armv8l" with an "l" on some Linux distros.
compiler-rt will autodetect that the "armhf" and/or "arm" architecture
can be built. We then replace the given triple's architecture with that.
Then if the triple's float ABI doesn't match, we change that. That new
triple is then used as the folder name.
If you select to build only the given triple, with COMPILER_RT_DEFAULT_TARGET_ONLY,
compiler-rt will not autodetect the architecture and for that I assume you
know what you're doing. In that case the library path will use the unomdified triple.
From what I can tell, this is how most large builds e.g Android and
Arm's Embedded Toolchain for llvm do things. I assume that big endian "armeb"
builds would end up doing this too.
Bare metal builds will not be using per target runtime dirs so they
remain as they were.
Depends on D139536
Reviewed By: MaskRay, phosek
Differential Revision: https://reviews.llvm.org/D140011
|
