In the discussion around #116792, @rjmccall mentioned that ARCMigrate
has been obsoleted and that we could go ahead and remove it from Clang,
so this patch does just that.
Use LLVM_VERSION_MAJOR instead as the maximum allowed value. This change
is needed to fix regression tests that fail when vendors set
CLANG_VERSION_MAJOR to a value that is lower than LLVM_VERSION_MAJOR
when building the compiler.
For example, clang/test/CodeGenCXX/mangle-concept.cpp fails with the
following error if -DCLANG_VERSION_MAJOR=17 is passed to cmake:
invalid value '19' in '-fclang-abi-compat=19'
This change removes the need to call the clang-bolt target in order to
apply bolt optimizations to clang. Now running `ninja clang` will build
a clang with bolt optimizations, and `ninja check-clang` and `ninja
install-clang` will test and install bolt optimized clang too.
The clang-bolt target has been kept for compatibilty reasons, but it is
now just an alias to the clang target.
Also, this new design for applying the bolt optimizations to clang will
be easier to generalize and use to optimize other binaries/libraries in
the project.
---------
Co-authored-by: Amir Ayupov <fads93@gmail.com>
Co-authored-by: Petr Hosek <phosek@google.com>
In Clang-BOLT step, preserve pre-BOLT Clang binary (as well as clang++
symlink).
Also modify the default set of BOLT flags:
- drop ICF (can mess with unwinders),
- switch from hfsort+ to cdsort (aliases),
- enable CDSplit,
- update debug sections.
Reviewers: maksfb
Reviewed By: maksfb
Pull Request: https://github.com/llvm/llvm-project/pull/109351
GCC usually doesn't warn about unrecognized -Wno-<foo> options, if no
diagnostics are printed. However if some diagnostics are printed, it
also mentions that there were unrecognized -Wno-<foo> options.
Before 4feae05c6abda364a9295aecfa600d7d4e7dfeb6, we checked for whether
-Wnested-anon-types was supported, and added the -Wno-<foo> form if the
positive form of the option was supported.
As of GCC 14, -Wnested-anon-types isn't supported, thus limit the use of
the option to actual Clang (and still only while using the GCC
compatible driver).
This avoids unnecessary mentions about unrecognized -Wno-<foo> options
when building with GCC.
This fixes two problems with the 2-stage PGO builds. The first problem
was that the stage2-instrumented and stage2 targets would not be built
on the second ninja invocation. For example:
This would work as expected.
$ ninja -v -C build stage2-instrumented-generate-profdata
Edit a file.
$ touch llvm/lib/Support/StringExtras.cpp
This would rebuild stage1 only and not build stage2-instrumented or
regenerate the profile data.
$ ninja -v -C build stage2-instrumented-generate-profdata
The second problem was that in some cases, the profile data would be
regenerated, but not all of the stage2 targets would be rebuilt. One
common scenario where this would happen is:
This would work as expected.
$ ninja -C build stage2-check-all
This would regenerate the profile data, but then only build the
targets that were needed for install, but weren't needed for
check-all. This would cause errors like:
ld.lld: error: Function Import: link error: linking module flags
'ProfileSummary': IDs have conflicting values in ...
This is because the executibles being built for the install target
used the new profile data, but they were linking with libraries that
used the old profile data.
$ ninja -C build stage2-install
With this change we can re-enable PGO for the release builds.
Update the folder titles for targets in the monorepository that have not
seen taken care of for some time. These are the folders that targets are
organized in Visual Studio and XCode (`set_property(TARGET <target>
PROPERTY FOLDER "<title>")`) when using the respective CMake's IDE
generator.
* Ensure that every target is in a folder
* Use a folder hierarchy with each LLVM subproject as a top-level folder
* Use consistent folder names between subprojects
* When using target-creating functions from AddLLVM.cmake, automatically
deduce the folder. This reduces the number of
`set_property`/`set_target_property`, but are still necessary when
`add_custom_target`, `add_executable`, `add_library`, etc. are used. A
LLVM_SUBPROJECT_TITLE definition is used for that in each subproject's
root CMakeLists.txt.
This patch remove 36 checks for compiler flags that are done via
invoking the compiler across LLVM, Clang, and LLDB. It's was made
possible by raising the bar for supported compilers that has been
happening over the years since the checks were added.
This is going to improve CMake configuration times. This topic was
highlighted in
https://discourse.llvm.org/t/cmake-compiler-flag-checks-are-really-slow-ideas-to-speed-them-up/78882.
`clang/tools/scan-build` is implemented in `perl`. However given `perl`
is not mentioned as a required dependency in `GettingStarted.rst` we
should make this optional.
This adds a `find_package(Perl)` check to cmake and disables the
`scan-build` tests when no perl executable is found.
Ideally we would also check if dependent perl modules like `Hash::Util`
are present on the system, but I don't see any pre-existing cmake macros
to easily test this. So for now I go with a plain check for the `perl`
package, at least this allows to use `cmake
-DCMAKE_DISABLE_FIND_PACKAGE_Perl=ON` to manually disable `perl` and the
tests.
This adds no real content, it just incrementally adds some scaffolding
necessary to enable a future patch to just add our first few ops.
Test Plan:
```
$ cmake -Sllvm -Bbuild -DCLANG_ENABLE_CIR=1 \
-DLLVM_ENABLE_PROJECTS='clang;mlir' \
-DCMAKE_BUILD_TYPE=Release -GNinja
$ ninja -C build check-clang
$ ninja -C build MLIRCIROpsIncGen
$ ninja -C build MLIRCIR
```
Reviewers: AaronBallman, erichkeane, bcardosolopes
Reviewed By: erichkeane, AaronBallman, bcardosolopes
Pull Request: https://github.com/llvm/llvm-project/pull/86080
Introduce a cmake variable that guards the inclusion of ClangIR into the
build of clang. Guard that we aren't trying to build without MLIR. Add
two subdirectories that, as of now, don't do anything.
Reviewers: bcardosolopes, erichkeane, petrhosek, Ericson2314
Reviewed By: bcardosolopes
Pull Request: https://github.com/llvm/llvm-project/pull/86078
Move the code adding top-level cmake/Modules directory to
CMAKE_MODULE_PATH prior to including `GetDarwinLinkerVersion`, in order
to fix standalone builds.
Fixes a regression introduced by
3bc71c2abfa00413fd15cf0e5c08af6ec0d4768b.
The HOST_LINK_VERSION is a hardcoded string in Darwin clang that detects
the linker version at configure time. The driver uses this information
to build the correct set of arguments for the linker. This patch detects
the linker version again during compiler-rt configuration and passes it
to the tests. This allows a clang built on a machine with a new linker
to run compiler-rt tests on a machine with an old linker.
rdar://125198603
unless USE_DEPRECATED_GCC_INSTALL_PREFIX (temporary escape hatch) is
set. Setting GCC_INSTALL_PREFIX leads to a warning for Clang 18.1
(#77537) and will be completely removed for Clang 20.
Link:
discourse.llvm.org/t/add-gcc-install-dir-deprecate-gcc-toolchain-and-remove-gcc-install-prefix/65091
Link:
discourse.llvm.org/t/correct-cmake-parameters-for-building-clang-and-lld-for-riscv/72833
This reverts commit 745883bba69007f1d2c5135f3d5b0f1efcfc82cd.
This is failing to configure on many of our bots:
https://lab.llvm.org/buildbot/#/builders/245/builds/19468
This did not get caught right away because generally bots only
clean the build every so often.
Split up and refactor CLANG_BOLT_INSTRUMENT into support for
BOLT instrumentation, perf no-LBR and perf with LBR profiling.
Differential Revision: https://reviews.llvm.org/D143617
Part of https://reviews.llvm.org/D158218
GCC_INSTALL_PREFIX is a rarely-used legacy option inherited from
pre-CMake build system and has configuration file replacement nowadays.
Many `clang/test/Driver` tests specify `--gcc-toolchain=` to prevent
failures when `GCC_INSTALL_PREFIX` is specified: some contributors add
them to fix tests and some just do cargo culting. This is not healthy
for contributors adding cross compilation support for this rarely used
option.
`DEFAULT_SYSROOT` should in spirit be deprecated as well, but a relative
path doesn't have good replacement, so don't deprecate it for now.
Link:
https://discourse.llvm.org/t/add-gcc-install-dir-deprecate-gcc-toolchain-and-remove-gcc-install-prefix/65091
Link:
https://discourse.llvm.org/t/correct-cmake-parameters-for-building-clang-and-lld-for-riscv/72833
---
With `GCC_INSTALL_PREFIX=/usr`, `clang a.c` behaves like
`clang --gcc-toolchain=/usr a.c`.
Here is a simplified version of GCC installation detection code.
```
if (OPT_gcc_install_dir_EQ)
return OPT_gcc_install_dir_EQ;
if (OPT_gcc_triple)
candidate_gcc_triples = {OPT_gcc_triple};
else
candidate_gcc_triples = collectCandidateTriples();
if (OPT_gcc_toolchain)
prefixes = {OPT_gcc_toolchain};
else
prefixes = {OPT_sysroot/usr, OPT_sysroot};
for (prefix : prefixes)
if "$prefix/lib/gcc" exists // also tries $prefix/lib/gcc-cross
for (triple : candidate_gcc_triples)
if "$prefix/lib/gcc/$triple" exists
return "$prefix/lib/gcc/$triple/$version"; // pick the largest version
```
`--gcc-toolchain=` specifies a directory where
`lib/gcc{,-cross}/$triple/$version` can be found. If you actually want
to use a specific version of GCC, specify something like
`--gcc-install-dir=/usr/lib/gcc/x86_64-linux-gnu/11` in a configuration
file. You can also specify `--gcc-triple=`.
On Debian and its derivatives where the target triple omits the vendor
part, the following ways are roughly equivalent, except that
`--gcc-install-dir=` specifies a version as well:
```
clang --gcc-toolchain=/usr a.c
clang --gcc-install-dir=/usr/lib/gcc/x86_64-linux-gnu/11 a.c
clang --gcc-triple=x86_64-linux-gnu a.c
```
The modules build trips over this frequently because there is no textual
include of the tablegen output, but the module includes it.
Differential revision: https://reviews.llvm.org/D157119
The required HTMLLogger include file needs python3 to run
resource_bundle.py to bundle all the html/css/js resources. However, if
user sets -DLLVM_INCLUDE_TESTS=OFF, CMake will not find python3 and the
resource bundler will never be executed. This patch set the python3 as a
required build dependency to fix this problem.
Patch By: Avimitin
Differential Revision: https://reviews.llvm.org/D152418
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.
When using compiler caching program like ccache, there is no point to
use them on external projects or multi-stage clang builds. As these
builds uses fresh from source code toolchain and will pollute the build
cache. If a compiler launcher is still required, a user can explicity
define `CMAKE_C_COMPILER_LAUNCHER` and `CMAKE_CXX_COMPILER_LAUNCHER` in
`CLANG_BOOTSTRAP_PASSTHROUGH` and `LLVM_EXTERNAL_PROJECT_PASSTHROUGH`
flags to enable compiler launcher in these builds.
Differential Revision: https://reviews.llvm.org/D144603
Without this dependency, it is possible that llvm-lib.exe will not be
built, in which case CMake will try to use lib.exe to build libraries,
but this tool cannot handle bitcode files.
Differential Revision: https://reviews.llvm.org/D148751
This does not help. The build is broken because compiler-rt-clear
deletes cmake generated files in STAMP_DIR/
This reverts commit da89ed99a16920e5986b14853d297322ccf7109e.
Fixes the following on cmake version 3.24.2:
'tools/clang/runtime/compiler-rt-stamps/compiler-rt-source_dirinfo.txt',
needed by 'tools/clang/runtime/compiler-rt-stamps/compiler-rt-download',
missing and no known rule to make it
Maybe related to https://cmake.org/cmake/help/latest/release/3.24.html#modules
(re-commit of cb38df4c4d3aee53107219a68749dc94fe70ff68 with the correct commit message)
Reviewed By: phosek, kwk
Differential Revision: https://reviews.llvm.org/D138472
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
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
This patch adds llvm-mt and llvm-rc to the Clang bootstrap
dependency when building the Clang under Windows.
Differential Revision: https://reviews.llvm.org/D143025
Instead of creating an extra clang-bolt binary and clang++-bolt symlink,
replace the original clang binary with BOLT-optimized one.
This fixes the issue with installing optimized binary as `install-clang`
target now copies the new version.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D139454
The `CLANG_OPENMP_NVPTX_DEFAULT_ARCH` is a static build configuration to
set the default OpenMP value. This was replaced in D141708 with the use
of the `nvptx-arch` tool which lets us query this at runtime instead.
This makes the behaviour between AMD and NVIDIA be more consisten and
allows users to have a default architecture that does not rely on
whoever configured the LLVM build.
Depends on D141708
Reviewed By: tra, MaskRay
Differential Revision: https://reviews.llvm.org/D141723
