mirrors/llvm-project
0
0
Fork 0
mirror of https://github.com/llvm/llvm-project.git synced 2025-04-18 01:06:39 +00:00
Code Issues Projects Releases Wiki Activity
llvm-project/llvm/CMakeLists.txt

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

1479 lines
59 KiB
CMake
Raw Permalink Normal View History

dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
# See docs/CMake.html for instructions about how to build LLVM with CMake.
Reland "[CMake] Bumps minimum version to 3.20.0. 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
2023-05-24 18:12:32 +02:00
cmake_minimum_required(VERSION 3.20.0)
Revert "Harmonize cmake_policy() across standalone builds of all projects" This reverts commit 88d7508dc479210f07abccb17f0194b66264b125. It's reported to break builds when symlinking other projects inside the `tools` directory.
2022-10-27 14:30:02 +02:00
Initial changes for llvm shared library build using explicit visibility annotations These are my initial build and code changes to supporting building llvm as shared library/DLL on windows(without force exporting all symbols) and making symbol visibility hidden by default on Linux which adding explicit symbol visibility macros to the whole llvm codebase. Updated cmake code to allow building llvm-shlib on windows by appending /WHOLEARCHIVE:lib to the linker options. Remove the hardcoded CMake error from using LLVM_BUILD_LLVM_DYLIB on windows. Updated CMake to define new macros to control conditional export macros in llvm/Support/Compiler.h Use /Zc:dllexportInlines- when compiling with clang-cl on windows with a opt out CMake option to disable using it. Replace some use of LLVM_EXTERNAL_VISIBILITY with new export macros. Some of the cmake and code changes are based on @tstellar's earlier PR https://github.com/llvm/llvm-project/pull/67502. I have Windows building using clang-cl, while for MSVC its at-least able to build libllvm, but some tests can't build because llvm iterator template metaprogramming that doesn't work well with dllexport. Linux should build without issue. My full branch is here https://github.com/fsfod/llvm-project/tree/llvm-export-api-20.0 and including all the auto generated export macros from clang tooling based system.
2024-09-06 18:51:44 +01:00
include(CMakeDependentOption)
Harmonize cmake_policy() across standalone builds of all projects Move `cmake_policy()` settings from `llvm/CMakeLists.txt` into a shared `cmake/modules/CMakePolicy.cmake`. Include it from all relevant projects that support standalone builds, in order to ensure that the policies are consistently set whether they are built in-tree or stand-alone. Differential Revision: https://reviews.llvm.org/D136572
2022-10-24 06:31:37 +02:00
set(LLVM_COMMON_CMAKE_UTILS ${CMAKE_CURRENT_SOURCE_DIR}/../cmake)
include(${LLVM_COMMON_CMAKE_UTILS}/Modules/CMakePolicy.cmake
NO_POLICY_SCOPE)
[cmake] Configure policy CMP0116 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
2021-04-22 10:08:53 -07:00
cmake: allow disabling building with the install name directory 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
2023-10-01 13:15:15 +00:00
# Builds with custom install names and installation rpath setups may not work
# in the build tree. Allow these cases to use CMake's default build tree
# behavior by setting `LLVM_NO_INSTALL_NAME_DIR_FOR_BUILD_TREE` to do this.
option(LLVM_NO_INSTALL_NAME_DIR_FOR_BUILD_TREE "If set, use CMake's default build tree install name directory logic (Darwin only)" OFF)
mark_as_advanced(LLVM_NO_INSTALL_NAME_DIR_FOR_BUILD_TREE)
if(NOT LLVM_NO_INSTALL_NAME_DIR_FOR_BUILD_TREE)
set(CMAKE_BUILD_WITH_INSTALL_NAME_DIR ON)
endif()
build: enable CMake policy 0077 Enable CMake policy 77. This alters the behavior of option. The old behavior would remove the value of the option from the cache and create a new one. The new behavior does not create the variable if it is defined already. This ensures that subsequent reconfigures will behave identically. This seems better than the setting of OLD - the desire is to ensure that it is set to OLD or NEW. llvm-svn: 361307
2019-05-21 20:28:32 +00:00
[cmake] Exposes LLVM version number in the runtimes. (#84641) This allows sharing the LLVM version number in libc++.
2024-03-11 17:43:14 +01:00
include(${LLVM_COMMON_CMAKE_UTILS}/Modules/LLVMVersion.cmake)
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
Export `LLVM_VERSION_MAJOR` CMake variable as a directory property (#83346) This allows users who include `llvm-project` as a subrepository to access the `LLVM_VERSION_MAJOR` variable on par with if they were relying on an installed LLVM and `FindLLVM.cmake`. They just need to do something like: ``` get_directory_property(LLVM_VERSION_MAJOR DIRECTORY "third_party/llvm-project/llvm" LLVM_VERSION_MAJOR) ``` Context: https://github.com/openxla/iree/pull/16606 -- like other projects with similar needs that I found by some googling, our work-around had been to rely on the CMake cached variable `CLANG_EXECUTABLE_VERSION`. Being cached, it over time inevitably ended up having a wrong value.
2024-03-05 09:59:28 -05:00
set_directory_properties(PROPERTIES LLVM_VERSION_MAJOR "${LLVM_VERSION_MAJOR}")
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
if (NOT PACKAGE_VERSION)
set(PACKAGE_VERSION
"${LLVM_VERSION_MAJOR}.${LLVM_VERSION_MINOR}.${LLVM_VERSION_PATCH}${LLVM_VERSION_SUFFIX}")
endif()
[cmake][NFC] Configuration for libLLVM.so symbol versioning Symbol versioning can prevent unintented install-time conflicts between different llvm versions. Users may need to override this for particular products (e.g. Julia), but this requires carrying a source code patch. This patch moves this ability to a configuration option. NFC for existing usage. Differential Revision: https://reviews.llvm.org/D118672
2022-01-31 17:56:42 -08:00
if(NOT DEFINED LLVM_SHLIB_SYMBOL_VERSION)
Introduce symbol versioning for clang-cpp (#116556) The situation that required symbol versions on the LLVM shared library can also happen for clang-cpp, although it is less common: different tools require different versions of the library, and through transitive dependencies a process ends up with multiple copies of clang-cpp. This causes havoc with ELF, because calls meant to go one version of the library end up with another. I've also considered introducing a symbol version globally, but for example the clang (C) library and other targets outside of LLVM/Clang, e.g. libc++, would not want that. So it's probably best if we keep it to those libraries.
2024-11-19 23:58:33 +01:00
# "Symbol version prefix for libLLVM.so and libclang-cpp.so"
[cmake] Add minor version to library SONAME (#79376) We need to do this now that we are bumping the minor release number when we create the release branch. This also results in a slight change to the library names for LLVM. The main library now has a more convential library name: 'libLLVM.so.$major.$minor'. The old library name: libLLVM-$major.so is now a symlink that points to the new library. However, the symlink is not present in the build directory. It is only present in the install directory. The library name was changed because it helped to keep the CMake changes more simple. Fixes #76273
2024-02-19 16:46:16 -08:00
set(LLVM_SHLIB_SYMBOL_VERSION "LLVM_${LLVM_VERSION_MAJOR}.${LLVM_VERSION_MINOR}")
[cmake][NFC] Configuration for libLLVM.so symbol versioning Symbol versioning can prevent unintented install-time conflicts between different llvm versions. Users may need to override this for particular products (e.g. Julia), but this requires carrying a source code patch. This patch moves this ability to a configuration option. NFC for existing usage. Differential Revision: https://reviews.llvm.org/D118672
2022-01-31 17:56:42 -08:00
endif()
[CMake] Disable mvsc warning for new versions Starting with VS 2019, CMake defaults to the x64 host toolchain, so the warning does not apply anymore. References: VS 2017 defaults to x86 https://cmake.org/cmake/help/latest/generator/Visual%20Studio%2015%202017.html?highlight=host#toolset-selection VS 2019 and 2022 default to x64 for x64 targets https://cmake.org/cmake/help/latest/generator/Visual%20Studio%2016%202019.html?highlight=host#toolset-selection https://cmake.org/cmake/help/latest/generator/Visual%20Studio%2017%202022.html?highlight=host#toolset-selection Differential Revision: https://reviews.llvm.org/D118228
2022-01-24 20:39:54 +01:00
if ((CMAKE_GENERATOR MATCHES "Visual Studio") AND (MSVC_TOOLSET_VERSION LESS 142) AND (CMAKE_GENERATOR_TOOLSET STREQUAL ""))
Update the documentation and CMake file for Visual Studio generators. By default, CMake uses a 32-bit toolchain, even when on a 64-bit platform targeting a 64-bit build. However, due to the size of the binaries involved, this can cause linker instabilities (such as the linker running out of memory). Guide people to the correct solution to get CMake to use the native toolchain. llvm-svn: 303912
2017-05-25 21:01:30 +00:00
message(WARNING "Visual Studio generators use the x86 host compiler by "
"default, even for 64-bit targets. This can result in linker "
"instability and out of memory errors. To use the 64-bit "
"host compiler, pass -Thost=x64 on the CMake command line.")
endif()
Fix issues building libraries as more than one type with Xcode Summary: CMake+Xcode doesn't seem to handle targets that only have object sources. This patch works around that limitation by adding a dummy soruce file to any library target that is generated by llvm_add_library when object libraries are generated. Object libraries are generated whenever llvm_add_library is passed more than one library type, which is now the default case for clang static libraries (which generate STATIC and OBJECT libraries). Reviewers: zturner, compnerd, joanlluch Reviewed By: joanlluch Subscribers: joanlluch, xbolva00, mgorny, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64300 llvm-svn: 365365
2019-07-08 18:29:29 +00:00
if (CMAKE_GENERATOR STREQUAL "Xcode" AND NOT CMAKE_OSX_ARCHITECTURES)
# Some CMake features like object libraries get confused if you don't
# explicitly specify an architecture setting with the Xcode generator.
set(CMAKE_OSX_ARCHITECTURES "x86_64")
endif()
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
project(LLVM
[cmake] Remove policy conditionals LLVM now requires a minimum of cmake 3.4.3, and all the policies currently being set are present in that cmake version, so the conditionals will always be true and are therefore unnecessary. The movation is that the conditionals can give the false impression that the policy settings are optional, whereas for example it's necessary to set CMP0056 in order for `check_linker_flags` to operate correctly after r316972. Inline the project version and language setting in the process. Differential Revision: https://reviews.llvm.org/D39442 llvm-svn: 317264
2017-11-02 20:33:36 +00:00
VERSION ${LLVM_VERSION_MAJOR}.${LLVM_VERSION_MINOR}.${LLVM_VERSION_PATCH}
LANGUAGES C CXX ASM)
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
[bolt][llvm][cmake] Use `CMAKE_INSTALL_LIBDIR` too Working back towards D130586. Bolt didn't use `LLVM_LIBDIR_SUFFIX` before, and has no in-tree reverse dependencies, it seems easier to add. The change in LLVM itself is to prevent some unexpected `lib64` from cropping up due to the `CMAKE_INSTALL_LIBDIR` defaulting logic. Differential Revision: https://reviews.llvm.org/D132297
2022-08-20 10:33:21 -04:00
if (NOT DEFINED CMAKE_INSTALL_LIBDIR AND DEFINED LLVM_LIBDIR_SUFFIX)
# Must go before `include(GNUInstallDirs)`.
set(CMAKE_INSTALL_LIBDIR "lib${LLVM_LIBDIR_SUFFIX}")
endif()
# Must go after `DEFINED LLVM_LIBDIR_SUFFIX` check.
set(LLVM_LIBDIR_SUFFIX "" CACHE STRING "Define suffix of library directory name (32/64)" )
# Must go after `project(..)`.
[cmake] Make include(GNUInstallDirs) always below project(..) Its defaulting logic must go after `project(..)` to work correctly, but `project(..)` is often in a standalone condition making this awkward, since the rest of the condition code may also need GNUInstallDirs. The good thing is there are the various standalone booleans, which I had missed before. This makes splitting the conditional blocks less awkward. Reviewed By: arichardson, phosek, beanz, ldionne, #libunwind, #libc, #libc_abi Differential Revision: https://reviews.llvm.org/D117639
2022-01-19 06:45:07 +00:00
include(GNUInstallDirs)
[CMake] Check CMAKE_CXX_STANDARD and error if it's to old Also nuke the old value out of the cache if it's there, otherwise it could lead to problems when the project increases the standard and the developer just runs the "make/ninja" program. Reviewed By: royjacobson Differential Revision: https://reviews.llvm.org/D131367
2022-08-07 21:52:37 +02:00
# This C++ standard is required to build LLVM.
set(LLVM_REQUIRED_CXX_STANDARD 17)
# If we find that the cache contains CMAKE_CXX_STANDARD it means that it's a old CMakeCache.txt
# and we can just inform the user and then reset it.
if($CACHE{CMAKE_CXX_STANDARD} AND $CACHE{CMAKE_CXX_STANDARD} LESS ${LLVM_REQUIRED_CXX_STANDARD})
message(WARNING "Resetting cache value for CMAKE_CXX_STANDARD to ${LLVM_REQUIRED_CXX_STANDARD}")
unset(CMAKE_CXX_STANDARD CACHE)
endif()
# if CMAKE_CXX_STANDARD is still set after the cache unset above it means that the user requested it
# and we allow it to be set to something newer than the required standard but otherwise we fail.
if(DEFINED CMAKE_CXX_STANDARD AND CMAKE_CXX_STANDARD LESS ${LLVM_REQUIRED_CXX_STANDARD})
message(FATAL_ERROR "Requested CMAKE_CXX_STANDARD=${CMAKE_CXX_STANDARD} which is less than the required ${LLVM_REQUIRED_CXX_STANDARD}.")
endif()
set(CMAKE_CXX_STANDARD ${LLVM_REQUIRED_CXX_STANDARD} CACHE STRING "C++ standard to conform to")
build: remove `LLVM_CXX_STD` extension point This extension point is not needed. Provide the equivalent option through `CMAKE_CXX_STANDARD` which mirrors the previous extension point. Rely on CMake to provide the check for the compiler instead.
2019-10-25 10:57:52 -07:00
set(CMAKE_CXX_STANDARD_REQUIRED YES)
[CMake] Check CMAKE_CXX_STANDARD and error if it's to old Also nuke the old value out of the cache if it's there, otherwise it could lead to problems when the project increases the standard and the developer just runs the "make/ninja" program. Reviewed By: royjacobson Differential Revision: https://reviews.llvm.org/D131367
2022-08-07 21:52:37 +02:00
repair cygwin build 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
2020-12-03 10:37:18 -05:00
if (CYGWIN)
# Cygwin is a bit stricter and lack things like 'strdup', 'stricmp', etc in
# c++xx mode.
set(CMAKE_CXX_EXTENSIONS YES)
else()
set(CMAKE_CXX_EXTENSIONS NO)
endif()
build: remove `LLVM_CXX_STD` extension point This extension point is not needed. Provide the equivalent option through `CMAKE_CXX_STANDARD` which mirrors the previous extension point. Rely on CMake to provide the check for the compiler instead.
2019-10-25 10:57:52 -07:00
[CMake] Silence message on multi-configuration generators The Xcode and Visual Studio generators always log "-- No build type selected, default to Debug". This is because CMake doesn't initialize "CMAKE_CONFIGURATION_TYPES" until the generator's EnableLanguage call gets hit. The first place EnableLanguage gets hit in our configuration is in the project() call. Since CMAKE_BUILD_TYPE isn't used until after we call project() it is safe to just move this check down a bit. llvm-svn: 279110
2016-08-18 18:17:28 +00:00
if (NOT CMAKE_BUILD_TYPE AND NOT CMAKE_CONFIGURATION_TYPES)
[CMake] Make omitting CMAKE_BUILD_TYPE an error After a lot of discussion in this diff the consensus was that it is really hard to guess the users intention with their LLVM build. Instead of trying to guess if Debug or Release is the correct default option we opted for just not specifying CMAKE_BUILD_TYPE a error. Discussion on discourse here: https://discourse.llvm.org/t/rfc-select-a-better-linker-by-default-or-warn-about-using-bfd Reviewed By: hans, mehdi_amini, aaron.ballman, jhenderson, MaskRay, awarzynski Differential Revision: https://reviews.llvm.org/D124153
2022-04-29 11:42:06 +02:00
message(FATAL_ERROR "
No build type selected. You need to pass -DCMAKE_BUILD_TYPE=<type> in order to configure LLVM.
Available options are:
* -DCMAKE_BUILD_TYPE=Release - For an optimized build with no assertions or debug info.
* -DCMAKE_BUILD_TYPE=Debug - For an unoptimized build with assertions and debug info.
* -DCMAKE_BUILD_TYPE=RelWithDebInfo - For an optimized build with no assertions but with debug info.
* -DCMAKE_BUILD_TYPE=MinSizeRel - For a build optimized for size instead of speed.
Learn more about these options in our documentation at https://llvm.org/docs/CMake.html#cmake-build-type
")
[CMake] Silence message on multi-configuration generators The Xcode and Visual Studio generators always log "-- No build type selected, default to Debug". This is because CMake doesn't initialize "CMAKE_CONFIGURATION_TYPES" until the generator's EnableLanguage call gets hit. The first place EnableLanguage gets hit in our configuration is in the project() call. Since CMAKE_BUILD_TYPE isn't used until after we call project() it is safe to just move this check down a bit. llvm-svn: 279110
2016-08-18 18:17:28 +00:00
endif()
[LLVM] Fix GetErrcMessages.cmake module for WoA GetErrcMessages.cmake module makes use of cmake's try_run which by default builds its sources in debug mode unless configured with CMAKE_TRY_COMPILE_CONFIGURATION. Debug builds on Windows sometimes fail when appropraite DLLs are not included in path. Also on Windows on Arm machines debug builds sometimes fail to link the correct debug DLLs. To fix this I am setting CMAKE_TRY_COMPILE_CONFIGURATION to active build configuration of currently configured LLVM project. This makes sure we select same build type for try_run/try_compile cmake modules as currently configured LLVM project. Reviewed By: zero9178 Differential Revision: https://reviews.llvm.org/D133482
2022-09-12 16:46:04 +05:00
# Set default build type for cmake's try_compile module.
# CMake 3.17 or newer sets CMAKE_DEFAULT_BUILD_TYPE to one of the
# items from CMAKE_CONFIGURATION_TYPES. Logic below can be further
# simplified once LLVM's minimum CMake version is updated to 3.17.
if(CMAKE_DEFAULT_BUILD_TYPE)
set(CMAKE_TRY_COMPILE_CONFIGURATION ${CMAKE_DEFAULT_BUILD_TYPE})
else()
if(CMAKE_CONFIGURATION_TYPES)
list(GET CMAKE_CONFIGURATION_TYPES 0 CMAKE_TRY_COMPILE_CONFIGURATION)
elseif(CMAKE_BUILD_TYPE)
set(CMAKE_TRY_COMPILE_CONFIGURATION ${CMAKE_BUILD_TYPE})
endif()
endif()
Add experimental support for unofficial monorepo-like directory layout Summary: This allows to have clang and llvm and the other subprojects side-by-side instead of nested. This can be used with the monorepo or multiple repos. It will help having a single set of sources checked out but allows to have a build directory with llvm and another one with llvm+clang. Basically it abstracts LLVM_EXTERNAL_xxxx_SOURCE_DIR making it more convenient by adopting a convention. Reviewers: bogner, beanz, jlebar Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D26365 llvm-svn: 286162
2016-11-07 22:13:38 +00:00
# Side-by-side subprojects layout: automatically set the
# LLVM_EXTERNAL_${project}_SOURCE_DIR using LLVM_ALL_PROJECTS
# This allows an easy way of setting up a build directory for llvm and another
# one for llvm+clang+... using the same sources.
[llvm] Remove libcxx, libcxxabi and libunwind from supported LLVM_ENABLE_PROJECTS This is a breaking change. If you were passing one of those three runtimes in LLVM_ENABLE_PROJECTS, you need to start passing them in LLVM_ENABLE_RUNTIMES instead. The runtimes in LLVM_ENABLE_RUNTIMES will start being built using the "bootstrapping build" instead, which means that they will be built using the just-built Clang. This is usually what you wanted anyway. If you were using LLVM_ENABLE_PROJECTS=all with the explicit goal of building these three runtimes, you can now use LLVM_ENABLE_RUNTIMES=all and these runtimes will be built using the bootstrapping build. NOTE: This is a re-application of 887b8bd733ea which had been reverted in 6b03a4fea0b4 because it broke the Sphinx documentation publishers. The Sphinx documentation publishers have now been moved to using the runtimes build, so this should not be an issue anymore. Differential Revision: https://reviews.llvm.org/D132480
2022-09-21 09:50:53 -04:00
set(LLVM_ALL_PROJECTS "bolt;clang;clang-tools-extra;compiler-rt;cross-project-tests;libc;libclc;lld;lldb;mlir;openmp;polly;pstl")
[AIX][CMake] Disable `openmp` as LLVM_ENABLE_PROJECTS (#110152) in favor of LLVM_ENABLE_RUNTIMES
2024-10-15 22:34:49 -04:00
if (${CMAKE_SYSTEM_NAME} MATCHES "AIX")
# Disallow 'openmp' as a LLVM PROJECT on AIX as the supported way is to use
# LLVM_ENABLE_RUNTIMES.
list(REMOVE_ITEM LLVM_ALL_PROJECTS openmp)
endif()
[Flang] add flang as a new subproject in cmake 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
2020-04-09 16:13:11 +01:00
# The flang project is not yet part of "all" projects (see C++ requirements)
set(LLVM_EXTRA_PROJECTS "flang")
# List of all known projects in the mono repo
Revert "Check for invalid projects passed in LLVM_ENABLE_PROJECTS" ``` 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 4121ac1e7f96d826b793bd7e29c181f1eb8168bf.
2021-09-18 13:56:54 +03:00
set(LLVM_KNOWN_PROJECTS "${LLVM_ALL_PROJECTS};${LLVM_EXTRA_PROJECTS}")
Add experimental support for unofficial monorepo-like directory layout Summary: This allows to have clang and llvm and the other subprojects side-by-side instead of nested. This can be used with the monorepo or multiple repos. It will help having a single set of sources checked out but allows to have a build directory with llvm and another one with llvm+clang. Basically it abstracts LLVM_EXTERNAL_xxxx_SOURCE_DIR making it more convenient by adopting a convention. Reviewers: bogner, beanz, jlebar Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D26365 llvm-svn: 286162
2016-11-07 22:13:38 +00:00
set(LLVM_ENABLE_PROJECTS "" CACHE STRING
[llvm][cmake] Normalize some indent - Change a stray tab to spaces - 4 not 2 spaces in second line of `set` like above. Reviewed By: mstorsjo Differential Revision: https://reviews.llvm.org/D116510
2022-01-03 01:29:39 +00:00
"Semicolon-separated list of projects to build (${LLVM_KNOWN_PROJECTS}), or \"all\".")
[llvm][Cmake] Expand "all" in LLVM_ENABLE_PROJECTS before other checks Differential Revision: https://reviews.llvm.org/D132454
2022-08-23 11:04:44 +02:00
# Make sure expansion happens first to not handle "all" in rest of the checks.
if( LLVM_ENABLE_PROJECTS STREQUAL "all" )
set( LLVM_ENABLE_PROJECTS ${LLVM_ALL_PROJECTS})
endif()
[llvm] Remove LLVM_CHECK_ENABLED_PROJECTS again This reverts commit 55f0b337087136554122f942fea951a357bc4a49 and follow-up reverts commit e9ea03c62ccc1ed4e3ed4f20e37640cfdd76cbcf. LLVM_EXTERNAL_PROJECTS is sufficient, see https://reviews.llvm.org/D110016
2021-09-24 18:48:08 -04:00
foreach(proj ${LLVM_ENABLE_PROJECTS})
[llvm][Cmake] Expand "all" in LLVM_ENABLE_PROJECTS before other checks Differential Revision: https://reviews.llvm.org/D132454
2022-08-23 11:04:44 +02:00
if (NOT proj STREQUAL "llvm" AND NOT "${proj}" IN_LIST LLVM_KNOWN_PROJECTS)
[llvm] Remove libcxx, libcxxabi and libunwind from supported LLVM_ENABLE_PROJECTS This is a breaking change. If you were passing one of those three runtimes in LLVM_ENABLE_PROJECTS, you need to start passing them in LLVM_ENABLE_RUNTIMES instead. The runtimes in LLVM_ENABLE_RUNTIMES will start being built using the "bootstrapping build" instead, which means that they will be built using the just-built Clang. This is usually what you wanted anyway. If you were using LLVM_ENABLE_PROJECTS=all with the explicit goal of building these three runtimes, you can now use LLVM_ENABLE_RUNTIMES=all and these runtimes will be built using the bootstrapping build. NOTE: This is a re-application of 887b8bd733ea which had been reverted in 6b03a4fea0b4 because it broke the Sphinx documentation publishers. The Sphinx documentation publishers have now been moved to using the runtimes build, so this should not be an issue anymore. Differential Revision: https://reviews.llvm.org/D132480
2022-09-21 09:50:53 -04:00
MESSAGE(FATAL_ERROR "${proj} isn't a known project: ${LLVM_KNOWN_PROJECTS}. Did you mean to enable it as a runtime in LLVM_ENABLE_RUNTIMES?")
Officially deprecate LLVM_ENABLE_PROJECTS for libc++, libc++abi and libunwind 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
2021-10-28 10:42:51 -04:00
endif()
endforeach()
Check for invalid projects passed in LLVM_ENABLE_PROJECTS 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
2021-09-18 02:38:17 +00:00
[flang][cmake] Enable the new driver by default 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
2021-05-04 15:52:15 +00:00
if ("flang" IN_LIST LLVM_ENABLE_PROJECTS)
if (NOT "mlir" IN_LIST LLVM_ENABLE_PROJECTS)
message(STATUS "Enabling MLIR as a dependency to flang")
list(APPEND LLVM_ENABLE_PROJECTS "mlir")
endif()
[flang][driver] Delete `f18` (i.e. the old Flang driver) 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
2021-07-12 08:44:38 +00:00
if (NOT "clang" IN_LIST LLVM_ENABLE_PROJECTS)
[Flang] Implicitly add clang if flang enabled (#123964) Clang is required to compile Flang. Instead of erroring-out if Clang is enabled, for convinience implicitly add it to `LLVM_ENABLE_PROJECTS`, consistent with how the MLIR dependency is handled. This is motivatated by the discussion on whether flang-rt shoud be enabled implicitly (https://discourse.llvm.org/t/buildbot-changes-with-llvm-enable-runtimes-flang-rt/83571/2). Since the answer was yet, clang would have been the only exception of not being enabled implicitly. Fixed with this commit.
2025-03-26 12:45:52 +01:00
message(STATUS "Enabling clang as a dependency to flang")
list(APPEND LLVM_ENABLE_PROJECTS "clang")
[flang][cmake] Enable the new driver by default 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
2021-05-04 15:52:15 +00:00
endif()
Automatically configure MLIR when flang is enabled This is more friendly than the "Unknown CMake command “mlir_tablegen”." that would be issued instead. Differential Revision: https://reviews.llvm.org/D80359
2020-05-21 05:30:49 +00:00
endif()
Previously if the user configured their build but then changed LLVM_ENABLED_PROJECT and reconfigured it had no effect on what projects were actually built. This was very confusing behaviour. The reason for this is that the value of the `LLVM_TOOL_<PROJECT>_BUILD` variables are already set. The problem here is that we have two sources of truth: * The projects listed in LLVM_ENABLE_PROJECTS. * The projects enabled/disabled with LLVM_TOOL_<PROJECT>_BUILD. At configure time we have no real way of knowing which source of truth the user wants so we apply the following heuristic: If the user ever sets `LLVM_ENABLE_PROJECTS` in the CMakeCache then that is used as the single source of truth and we force the `LLVM_TOOL_<PROJECT>_BUILD` CMake cache variables to have the appropriate values that match the contents of the `LLVM_ENABLE_PROJECTS`. If the user never sets `LLVM_ENABLE_PROJECTS` then they can continue to use and set the `LLVM_TOOL_<PROJECT>_BUILD` variables as the "source of truth". The problem with this approach is that if the user ever tries to use both `LLVM_ENABLE_PROJECTS` and `LLVM_TOOL_<PROJECT>_BUILD` for the same build directory then any user set value for `LLVM_TOOL_<PROJECT>_BUILD` variables will get overwriten, likely without the user noticing. Hopefully the above shouldn't matter in practice because the LLVM_TOOL_<PROJECT>_BUILD variables are not documented, but LLVM_ENABLE_PROJECTS is. We should probably deprecate the `LLVM_TOOL_<PROJECT>_BUILD` variables at some point by turning them into to regular CMake variables that don't live in the CMake cache. Differential Revision: https://reviews.llvm.org/D57535 llvm-svn: 353148
2019-02-05 08:47:28 +00:00
[libc] Deprecate LLVM_ENABLE_PROJECTS in favor of LLVM_ENABLE_RUNTIMES. (#117265) We plan to make this a hard error in the LLVM 21 release. Link: #78479
2024-12-02 14:47:58 -08:00
if ("libc" IN_LIST LLVM_ENABLE_PROJECTS)
message(WARNING "Using LLVM_ENABLE_PROJECTS=libc is deprecated now, and will "
"become a fatal error in the LLVM 21 release. Please use "
"-DLLVM_ENABLE_RUNTIMES=libc or see the instructions at "
"https://libc.llvm.org/ for building the runtimes.")
endif()
[compiler-rt] Deprecate LLVM_ENABLE_PROJECTS in favor of LLVM_ENABLE_RUNTIMES (#124016) We plan to make this a hard error in the LLVM 21 release. Link #124012
2025-01-27 22:32:38 -08:00
if ("compiler-rt" IN_LIST LLVM_ENABLE_PROJECTS)
message(WARNING "Using LLVM_ENABLE_PROJECTS=compiler-rt is deprecated now, and will "
"become a fatal error in the LLVM 21 release. Please use "
"-DLLVM_ENABLE_RUNTIMES=compiler-rt or see the instructions at "
"https://compiler-rt.llvm.org/ for building the runtimes.")
endif()
[Flang] LLVM_ENABLE_RUNTIMES=flang-rt (#110217) Extract Flang's runtime library to use the LLVM_ENABLE_RUNTIME mechanism. It will only become active when `LLVM_ENABLE_RUNTIMES=flang-rt` is used, which also changes the `FLANG_INCLUDE_RUNTIME` to `OFF` so the old runtime build rules do not conflict. This also means that unless `LLVM_ENABLE_RUNTIMES=flang-rt` is passed, nothing changes with the current build process. Motivation: * Consistency with LLVM's other runtime libraries (compiler-rt, libc, libcxx, openmp offload, ...) * Allows compiling the runtime for multiple targets at once using the LLVM_RUNTIME_TARGETS configuration options * Installs the runtime into the compiler's per-target resource directory so it can be automatically found even when cross-compiling Also see RFC discussion at https://discourse.llvm.org/t/rfc-use-llvm-enable-runtimes-for-flangs-runtime/80826
2025-02-16 15:39:52 +01:00
if ("flang-rt" IN_LIST LLVM_ENABLE_RUNTIMES)
if (NOT "flang" IN_LIST LLVM_ENABLE_PROJECTS)
message(FATAL_ERROR "Flang is not enabled, but is required for the Flang-RT runtime")
endif ()
endif ()
[runtimes][NFC] Colocate handling of LLVM_ENABLE_PROJECTS and LLVM_ENABLE_RUNTIMES This will make the following patches to migrate projects off of the LLVM_ENABLE_PROJECTS build onto the LLVM_ENABLE_RUNTIMES build much easier to comprehend. This patch should be a NFC since it keeps the same set of runtimes being built by default. Differential Revision: https://reviews.llvm.org/D132478
2022-08-23 11:10:18 -04:00
# Select the runtimes to build
[runtimes] Shrink the set of runtimes included in the bootstrapping build by default This patch is in preparation for removing libcxx, libcxxabi and libunwind from LLVM_ENABLE_PROJECTS. When we make that switch, folks who were previously using LLVM_ENABLE_PROJECTS=all in order to build those runtimes will be able to add LLVM_ENABLE_RUNTIMES=all to start building those projects using the bootstrapping build. This is technically a breaking change for folks who had been using LLVM_ENABLE_RUNTIMES=all, however I suspect the set of people currently doing that is extremely small, so this is likely acceptable (more than breaking folks who are using LLVM_ENABLE_PROJECTS=all). Differential Revision: https://reviews.llvm.org/D132479
2022-08-23 11:14:15 -04:00
#
# As we migrate runtimes to using the bootstrapping build, the set of default runtimes
# should grow as we remove those runtimes from LLVM_ENABLE_PROJECTS above.
set(LLVM_DEFAULT_RUNTIMES "libcxx;libcxxabi;libunwind")
[Flang] LLVM_ENABLE_RUNTIMES=flang-rt (#110217) Extract Flang's runtime library to use the LLVM_ENABLE_RUNTIME mechanism. It will only become active when `LLVM_ENABLE_RUNTIMES=flang-rt` is used, which also changes the `FLANG_INCLUDE_RUNTIME` to `OFF` so the old runtime build rules do not conflict. This also means that unless `LLVM_ENABLE_RUNTIMES=flang-rt` is passed, nothing changes with the current build process. Motivation: * Consistency with LLVM's other runtime libraries (compiler-rt, libc, libcxx, openmp offload, ...) * Allows compiling the runtime for multiple targets at once using the LLVM_RUNTIME_TARGETS configuration options * Installs the runtime into the compiler's per-target resource directory so it can be automatically found even when cross-compiling Also see RFC discussion at https://discourse.llvm.org/t/rfc-use-llvm-enable-runtimes-for-flangs-runtime/80826
2025-02-16 15:39:52 +01:00
set(LLVM_SUPPORTED_RUNTIMES "libc;libunwind;libcxxabi;pstl;libcxx;compiler-rt;openmp;llvm-libgcc;offload;flang-rt")
[runtimes][NFC] Colocate handling of LLVM_ENABLE_PROJECTS and LLVM_ENABLE_RUNTIMES This will make the following patches to migrate projects off of the LLVM_ENABLE_PROJECTS build onto the LLVM_ENABLE_RUNTIMES build much easier to comprehend. This patch should be a NFC since it keeps the same set of runtimes being built by default. Differential Revision: https://reviews.llvm.org/D132478
2022-08-23 11:10:18 -04:00
set(LLVM_ENABLE_RUNTIMES "" CACHE STRING
"Semicolon-separated list of runtimes to build, or \"all\" (${LLVM_DEFAULT_RUNTIMES}). Supported runtimes are ${LLVM_SUPPORTED_RUNTIMES}.")
if(LLVM_ENABLE_RUNTIMES STREQUAL "all")
set(LLVM_ENABLE_RUNTIMES ${LLVM_DEFAULT_RUNTIMES})
endif()
foreach(proj IN LISTS LLVM_ENABLE_RUNTIMES)
if (NOT "${proj}" IN_LIST LLVM_SUPPORTED_RUNTIMES)
[LLVM][Runtimes] Surround unknown runtime with "" So that when you do something like: -DLLVM_ENABLE_RUNTIMES=;compiler-rt;libcxx;libcxxabi;libunwind You get: Runtime "" is not a supported runtime. Supported runtimes are: Instead of: Runtime is not a supported runtime. Supported runtimes are: Which implies that "Runtime" is the name of the runtime you tried to build, but in fact it was "".
2022-12-05 11:33:29 +00:00
message(FATAL_ERROR "Runtime \"${proj}\" is not a supported runtime. Supported runtimes are: ${LLVM_SUPPORTED_RUNTIMES}")
[runtimes][NFC] Colocate handling of LLVM_ENABLE_PROJECTS and LLVM_ENABLE_RUNTIMES This will make the following patches to migrate projects off of the LLVM_ENABLE_PROJECTS build onto the LLVM_ENABLE_RUNTIMES build much easier to comprehend. This patch should be a NFC since it keeps the same set of runtimes being built by default. Differential Revision: https://reviews.llvm.org/D132478
2022-08-23 11:10:18 -04:00
endif()
endforeach()
[libc] Repurpose `LIBC_GPU_BUILD` option to enable the new format (#82848) Summary: We previously used the `LIBC_GPU_BUILD` option to control whether or not the GPU build was enabled. This was recently replaced with a new format that allows treating the GPU targets more directly. However, the new format is somewhat difficult to use for people unfamiliar with the runtimes builds, and the removal of this option somewhat broke backward compatibility. This patch seeks to simplify enabling the GPU build by repurposing the old enabling option and convert it to the new interface. Unsure what the rules are here, since this is technically a `LIBC` option living in the LLVM location.
2024-03-13 14:25:22 -05:00
# Set a shorthand option to enable the GPU build of the 'libc' project.
option(LIBC_GPU_BUILD "Enable the 'libc' project targeting the GPU" OFF)
if(LIBC_GPU_BUILD)
if(LLVM_RUNTIME_TARGETS)
list(APPEND LLVM_RUNTIME_TARGETS "nvptx64-nvidia-cuda" "amdgcn-amd-amdhsa")
else()
set(LLVM_RUNTIME_TARGETS "default;nvptx64-nvidia-cuda;amdgcn-amd-amdhsa")
endif()
list(APPEND RUNTIMES_nvptx64-nvidia-cuda_LLVM_ENABLE_RUNTIMES "libc")
list(APPEND RUNTIMES_amdgcn-amd-amdhsa_LLVM_ENABLE_RUNTIMES "libc")
endif()
[libc] Only enable `LLVM_FULL_BUILD_MODE` by default for GPU targets (#84664) Summary: Currently we have a conditional that turns the full build on by default if it is a default target. This used to work fine when the GPU was the only target that was ever present. However, we've recently changed to allow building multiple of these at the same time. That means we should have the ability to build overlay mode in the CPU mode and full build in the GPU mode. This patch makes some simple adjustments to pass the arguments per-triple. This slightly extends the existing `-DRUNTIMES_` argument support to also transform any extra CMake inputs rather than just the passed CMake variables.
2024-03-11 09:05:49 -05:00
foreach(_name ${LLVM_RUNTIME_TARGETS})
if("libc" IN_LIST RUNTIMES_${_name}_LLVM_ENABLE_RUNTIMES)
if("${_name}" STREQUAL "amdgcn-amd-amdhsa" OR "${_name}" STREQUAL "nvptx64-nvidia-cuda")
set(LLVM_LIBC_GPU_BUILD ON)
endif()
endif()
endforeach()
[libc] Build the GPU during the projects setup like libc-hdrgen (#84667) Summary: The libc build has a few utilties that need to be built before we can do everything in the full build. The one requirement currently is the `libc-hdrgen` binary. If we are doing a full build runtimes mode we first add `libc` to the projects list and then only use the `projects` portion to buld the `libc` portion. We also use utilities for the GPU build, namely the loader utilities. Previously we would build these tools on-demand inside of the cross-build, which tool some hacky workarounds for the dependency finding and target triple. This patch instead just builds them similarly to libc-hdrgen and then passses them in. We now either pass it manually it it was built, or just look it up like we do with the other `clang` tools. Depends on https://github.com/llvm/llvm-project/pull/84664
2024-03-11 09:18:47 -05:00
if("${LIBC_TARGET_TRIPLE}" STREQUAL "amdgcn-amd-amdhsa" OR
"${LIBC_TARGET_TRIPLE}" STREQUAL "nvptx64-nvidia-cuda")
set(LLVM_LIBC_GPU_BUILD ON)
endif()
[llvm][cmake] Do not emit error on `libc`'s use of project + runtime build (#110038) Summary: The `libc` project automatically adds `libc` to the projects list if it's in the runtimes list. This then causes it to enter the projects directory to bootstrap a handful of utilities, This usage conflicts with a new error message with effectively stopped us from doing this. This patch weakens the error message to permit this single case.
2024-09-25 14:32:29 -07:00
Previously if the user configured their build but then changed LLVM_ENABLED_PROJECT and reconfigured it had no effect on what projects were actually built. This was very confusing behaviour. The reason for this is that the value of the `LLVM_TOOL_<PROJECT>_BUILD` variables are already set. The problem here is that we have two sources of truth: * The projects listed in LLVM_ENABLE_PROJECTS. * The projects enabled/disabled with LLVM_TOOL_<PROJECT>_BUILD. At configure time we have no real way of knowing which source of truth the user wants so we apply the following heuristic: If the user ever sets `LLVM_ENABLE_PROJECTS` in the CMakeCache then that is used as the single source of truth and we force the `LLVM_TOOL_<PROJECT>_BUILD` CMake cache variables to have the appropriate values that match the contents of the `LLVM_ENABLE_PROJECTS`. If the user never sets `LLVM_ENABLE_PROJECTS` then they can continue to use and set the `LLVM_TOOL_<PROJECT>_BUILD` variables as the "source of truth". The problem with this approach is that if the user ever tries to use both `LLVM_ENABLE_PROJECTS` and `LLVM_TOOL_<PROJECT>_BUILD` for the same build directory then any user set value for `LLVM_TOOL_<PROJECT>_BUILD` variables will get overwriten, likely without the user noticing. Hopefully the above shouldn't matter in practice because the LLVM_TOOL_<PROJECT>_BUILD variables are not documented, but LLVM_ENABLE_PROJECTS is. We should probably deprecate the `LLVM_TOOL_<PROJECT>_BUILD` variables at some point by turning them into to regular CMake variables that don't live in the CMake cache. Differential Revision: https://reviews.llvm.org/D57535 llvm-svn: 353148
2019-02-05 08:47:28 +00:00
# LLVM_ENABLE_PROJECTS_USED is `ON` if the user has ever used the
# `LLVM_ENABLE_PROJECTS` CMake cache variable. This exists for
# several reasons:
#
# * As an indicator that the `LLVM_ENABLE_PROJECTS` list is now the single
# source of truth for which projects to build. This means we will ignore user
# supplied `LLVM_TOOL_<project>_BUILD` CMake cache variables and overwrite
# them.
#
# * The case where the user previously had `LLVM_ENABLE_PROJECTS` set to a
# non-empty list but now the user wishes to disable building all other projects
# by setting `LLVM_ENABLE_PROJECTS` to an empty string. In that case we still
# need to set the `LLVM_TOOL_${upper_proj}_BUILD` variables so that we disable
# building all the projects that were previously enabled.
set(LLVM_ENABLE_PROJECTS_USED OFF CACHE BOOL "")
mark_as_advanced(LLVM_ENABLE_PROJECTS_USED)
if (LLVM_ENABLE_PROJECTS_USED OR NOT LLVM_ENABLE_PROJECTS STREQUAL "")
set(LLVM_ENABLE_PROJECTS_USED ON CACHE BOOL "" FORCE)
[Flang] add flang as a new subproject in cmake 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
2020-04-09 16:13:11 +01:00
foreach(proj ${LLVM_KNOWN_PROJECTS} ${LLVM_EXTERNAL_PROJECTS})
Previously if the user configured their build but then changed LLVM_ENABLED_PROJECT and reconfigured it had no effect on what projects were actually built. This was very confusing behaviour. The reason for this is that the value of the `LLVM_TOOL_<PROJECT>_BUILD` variables are already set. The problem here is that we have two sources of truth: * The projects listed in LLVM_ENABLE_PROJECTS. * The projects enabled/disabled with LLVM_TOOL_<PROJECT>_BUILD. At configure time we have no real way of knowing which source of truth the user wants so we apply the following heuristic: If the user ever sets `LLVM_ENABLE_PROJECTS` in the CMakeCache then that is used as the single source of truth and we force the `LLVM_TOOL_<PROJECT>_BUILD` CMake cache variables to have the appropriate values that match the contents of the `LLVM_ENABLE_PROJECTS`. If the user never sets `LLVM_ENABLE_PROJECTS` then they can continue to use and set the `LLVM_TOOL_<PROJECT>_BUILD` variables as the "source of truth". The problem with this approach is that if the user ever tries to use both `LLVM_ENABLE_PROJECTS` and `LLVM_TOOL_<PROJECT>_BUILD` for the same build directory then any user set value for `LLVM_TOOL_<PROJECT>_BUILD` variables will get overwriten, likely without the user noticing. Hopefully the above shouldn't matter in practice because the LLVM_TOOL_<PROJECT>_BUILD variables are not documented, but LLVM_ENABLE_PROJECTS is. We should probably deprecate the `LLVM_TOOL_<PROJECT>_BUILD` variables at some point by turning them into to regular CMake variables that don't live in the CMake cache. Differential Revision: https://reviews.llvm.org/D57535 llvm-svn: 353148
2019-02-05 08:47:28 +00:00
string(TOUPPER "${proj}" upper_proj)
string(REGEX REPLACE "-" "_" upper_proj ${upper_proj})
if ("${proj}" IN_LIST LLVM_ENABLE_PROJECTS)
message(STATUS "${proj} project is enabled")
set(SHOULD_ENABLE_PROJECT TRUE)
set(PROJ_DIR "${CMAKE_CURRENT_SOURCE_DIR}/../${proj}")
if(NOT EXISTS "${PROJ_DIR}" OR NOT IS_DIRECTORY "${PROJ_DIR}")
message(FATAL_ERROR "LLVM_ENABLE_PROJECTS requests ${proj} but directory not found: ${PROJ_DIR}")
endif()
[CMake] Allow LLVM_EXTERNAL_<proj>_SOURCE_DIR to be overridden if it is empty. This makes adding projects to LLVM_ENABLE_PROJECTS possible. Also its type should be PATH. https://bugs.llvm.org/show_bug.cgi?id=42698 Reviewers: beanz, greened, chapuni Reviewed by: beanz Differential Revision: https://reviews.llvm.org/D65045 llvm-svn: 367144
2019-07-26 19:25:57 +00:00
if( LLVM_EXTERNAL_${upper_proj}_SOURCE_DIR STREQUAL "" )
set(LLVM_EXTERNAL_${upper_proj}_SOURCE_DIR "${CMAKE_CURRENT_SOURCE_DIR}/../${proj}" CACHE PATH "" FORCE)
else()
set(LLVM_EXTERNAL_${upper_proj}_SOURCE_DIR "${CMAKE_CURRENT_SOURCE_DIR}/../${proj}" CACHE PATH "")
endif()
Cmake: allow using LLVM_EXTERNAL_PROJECTS with LLVM_ENABLE_PROJECTS The current code iterates over the combination of LLVM_EXTERNAL_PROJECTS and LLVM_ENABLE_PROJECTS, but then disables projects that are only in the former. If a project is in LLVM_EXTERNAL_PROJECTS, it should be enabled. See also llvm-commits thread on r354060. Differential revision: https://reviews.llvm.org/D62289 llvm-svn: 361751
2019-05-27 09:03:00 +00:00
elseif ("${proj}" IN_LIST LLVM_EXTERNAL_PROJECTS)
message(STATUS "${proj} project is enabled")
set(SHOULD_ENABLE_PROJECT TRUE)
Previously if the user configured their build but then changed LLVM_ENABLED_PROJECT and reconfigured it had no effect on what projects were actually built. This was very confusing behaviour. The reason for this is that the value of the `LLVM_TOOL_<PROJECT>_BUILD` variables are already set. The problem here is that we have two sources of truth: * The projects listed in LLVM_ENABLE_PROJECTS. * The projects enabled/disabled with LLVM_TOOL_<PROJECT>_BUILD. At configure time we have no real way of knowing which source of truth the user wants so we apply the following heuristic: If the user ever sets `LLVM_ENABLE_PROJECTS` in the CMakeCache then that is used as the single source of truth and we force the `LLVM_TOOL_<PROJECT>_BUILD` CMake cache variables to have the appropriate values that match the contents of the `LLVM_ENABLE_PROJECTS`. If the user never sets `LLVM_ENABLE_PROJECTS` then they can continue to use and set the `LLVM_TOOL_<PROJECT>_BUILD` variables as the "source of truth". The problem with this approach is that if the user ever tries to use both `LLVM_ENABLE_PROJECTS` and `LLVM_TOOL_<PROJECT>_BUILD` for the same build directory then any user set value for `LLVM_TOOL_<PROJECT>_BUILD` variables will get overwriten, likely without the user noticing. Hopefully the above shouldn't matter in practice because the LLVM_TOOL_<PROJECT>_BUILD variables are not documented, but LLVM_ENABLE_PROJECTS is. We should probably deprecate the `LLVM_TOOL_<PROJECT>_BUILD` variables at some point by turning them into to regular CMake variables that don't live in the CMake cache. Differential Revision: https://reviews.llvm.org/D57535 llvm-svn: 353148
2019-02-05 08:47:28 +00:00
else()
message(STATUS "${proj} project is disabled")
set(SHOULD_ENABLE_PROJECT FALSE)
endif()
# Force `LLVM_TOOL_${upper_proj}_BUILD` variables to have values that
# corresponds with `LLVM_ENABLE_PROJECTS`. This prevents the user setting
# `LLVM_TOOL_${upper_proj}_BUILD` variables externally. At some point
# we should deprecate allowing users to set these variables by turning them
# into normal CMake variables rather than cache variables.
set(LLVM_TOOL_${upper_proj}_BUILD
${SHOULD_ENABLE_PROJECT}
CACHE
BOOL "Whether to build ${upper_proj} as part of LLVM" FORCE
)
endforeach()
endif()
unset(SHOULD_ENABLE_PROJECT)
Add experimental support for unofficial monorepo-like directory layout Summary: This allows to have clang and llvm and the other subprojects side-by-side instead of nested. This can be used with the monorepo or multiple repos. It will help having a single set of sources checked out but allows to have a build directory with llvm and another one with llvm+clang. Basically it abstracts LLVM_EXTERNAL_xxxx_SOURCE_DIR making it more convenient by adopting a convention. Reviewers: bogner, beanz, jlebar Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D26365 llvm-svn: 286162
2016-11-07 22:13:38 +00:00
Revert "[CMake] Remove custom ccache CMake logic" This reverts commit 0fad18c44a14b909a1aa47165021273d4c10a665. We need bots to be updated first.
2023-02-13 08:56:56 +01:00
# Build llvm with ccache if the package is present
set(LLVM_CCACHE_BUILD OFF CACHE BOOL "Set to ON for a ccache enabled build")
if(LLVM_CCACHE_BUILD)
find_program(CCACHE_PROGRAM ccache)
if(CCACHE_PROGRAM)
set(LLVM_CCACHE_MAXSIZE "" CACHE STRING "Size of ccache")
set(LLVM_CCACHE_DIR "" CACHE STRING "Directory to keep ccached data")
set(LLVM_CCACHE_PARAMS "CCACHE_CPP2=yes CCACHE_HASHDIR=yes"
CACHE STRING "Parameters to pass through to ccache")
if(NOT CMAKE_SYSTEM_NAME MATCHES "Windows")
set(CCACHE_PROGRAM "${LLVM_CCACHE_PARAMS} ${CCACHE_PROGRAM}")
if (LLVM_CCACHE_MAXSIZE)
set(CCACHE_PROGRAM "CCACHE_MAXSIZE=${LLVM_CCACHE_MAXSIZE} ${CCACHE_PROGRAM}")
endif()
if (LLVM_CCACHE_DIR)
set(CCACHE_PROGRAM "CCACHE_DIR=${LLVM_CCACHE_DIR} ${CCACHE_PROGRAM}")
endif()
set_property(GLOBAL PROPERTY RULE_LAUNCH_COMPILE ${CCACHE_PROGRAM})
else()
if(LLVM_CCACHE_MAXSIZE OR LLVM_CCACHE_DIR OR
NOT LLVM_CCACHE_PARAMS MATCHES "CCACHE_CPP2=yes CCACHE_HASHDIR=yes")
message(FATAL_ERROR "Ccache configuration through CMake is not supported on Windows. Please use environment variables.")
endif()
# RULE_LAUNCH_COMPILE should work with Ninja but currently has issues
# with cmd.exe and some MSVC tools other than cl.exe
set(CMAKE_C_COMPILER_LAUNCHER ${CCACHE_PROGRAM})
set(CMAKE_CXX_COMPILER_LAUNCHER ${CCACHE_PROGRAM})
endif()
else()
message(FATAL_ERROR "Unable to find the program ccache. Set LLVM_CCACHE_BUILD to OFF")
endif()
Build llvm with ccache if package is present This patch has the following changes The CMake variable LLVM_CCACHE_BUILD is set to OFF by default. Set this to ON for a ccache enabled build CCACHE_CPP2 is required to compile the source file directly instead of compiling the preprocessed file. This will help WERROR is turned ON for a host clang compiler The below two options makes more sense in the context of a buildbot CCACHE_HASHDIR is required to maintain the separate cached data across builders. This will also help the debuggers to point to the correct source location CCACHE_SIZE is important in the perspective of buildbot to increase the limit on the amount of data to hold in cache for faster compilation CCACHE_DIR is used to save the cached data to a specific directory. llvm-svn: 277389
2016-08-01 21:28:03 +00:00
endif()
[CMake] Support passing arguments to build tool for external projects Add CMake variable LLVM_EXTERNAL_PROJECT_BUILD_TOOL_ARGS to allow arguments to be passed to the native tool used in CMake --build invocations for external projects. Can be used to pass extra arguments for enhanced versions of build tools, e.g. distributed build options. Differential Revision: https://reviews.llvm.org/D115815
2021-12-14 14:34:44 +00:00
set(LLVM_EXTERNAL_PROJECT_BUILD_TOOL_ARGS "" CACHE STRING
"Optional arguments for the native tool used in CMake --build invocations for external projects.")
mark_as_advanced(LLVM_EXTERNAL_PROJECT_BUILD_TOOL_ARGS)
[CMake] [Darwin] Add support for debugging tablegen dependencies This patch adds an option to the build system LLVM_DEPENDENCY_DEBUGGING. Over time I plan to extend this to do more complex verifications, but the initial patch causes compile errors wherever there is missing a dependency on intrinsics_gen. Because intrinsics_gen is a compile-time dependency not a link-time dependency, everything that relies on the headers generated in intrinsics_gen needs an explicit dependency. llvm-svn: 287207
2016-11-17 04:36:59 +00:00
option(LLVM_DEPENDENCY_DEBUGGING "Dependency debugging mode to verify correctly expressed library dependencies (Darwin only)" OFF)
# Some features of the LLVM build may be disallowed when dependency debugging is
# enabled. In particular you cannot use ccache because we want to force compile
# operations to always happen.
if(LLVM_DEPENDENCY_DEBUGGING)
if(NOT CMAKE_HOST_APPLE)
message(FATAL_ERROR "Dependency debugging is only currently supported on Darwin hosts.")
endif()
Revert "[CMake] Remove custom ccache CMake logic" This reverts commit 0fad18c44a14b909a1aa47165021273d4c10a665. We need bots to be updated first.
2023-02-13 08:56:56 +01:00
if(LLVM_CCACHE_BUILD)
message(FATAL_ERROR "Cannot enable dependency debugging while using ccache.")
[CMake] [Darwin] Add support for debugging tablegen dependencies This patch adds an option to the build system LLVM_DEPENDENCY_DEBUGGING. Over time I plan to extend this to do more complex verifications, but the initial patch causes compile errors wherever there is missing a dependency on intrinsics_gen. Because intrinsics_gen is a compile-time dependency not a link-time dependency, everything that relies on the headers generated in intrinsics_gen needs an explicit dependency. llvm-svn: 287207
2016-11-17 04:36:59 +00:00
endif()
endif()
[Tablegen] Instrumenting table gen DAGGenISelDAG To help assist in debugging ISEL or to prioritize GlobalISel backend work, this patch adds two more tables to <Target>GenISelDAGISel.inc - one which contains the patterns that are used during selection and the other containing include source location of the patterns Enabled through CMake varialbe LLVM_ENABLE_DAGISEL_COV llvm-svn: 295081
2017-02-14 18:32:41 +00:00
option(LLVM_ENABLE_DAGISEL_COV "Debug: Prints tablegen patterns that were used for selecting" OFF)
[globalisel][tablegen] Generate rule coverage and use it to identify untested rules Summary: This patch adds a LLVM_ENABLE_GISEL_COV which, like LLVM_ENABLE_DAGISEL_COV, causes TableGen to instrument the generated table to collect rule coverage information. However, LLVM_ENABLE_GISEL_COV goes a bit further than LLVM_ENABLE_DAGISEL_COV. The information is written to files (${CMAKE_BINARY_DIR}/gisel-coverage-* by default). These files can then be concatenated into ${LLVM_GISEL_COV_PREFIX}-all after which TableGen will read this information and use it to emit warnings about untested rules. This technique could also be used by SelectionDAG and can be further extended to detect hot rules and give them priority over colder rules. Usage: * Enable LLVM_ENABLE_GISEL_COV in CMake * Build the compiler and run some tests * cat gisel-coverage-[0-9]* > gisel-coverage-all * Delete lib/Target/*/*GenGlobalISel.inc* * Build the compiler Known issues: * ${LLVM_GISEL_COV_PREFIX}-all must be generated as a manual step due to a lack of a portable 'cat' command. It should be the concatenation of all ${LLVM_GISEL_COV_PREFIX}-[0-9]* files. * There's no mechanism to discard coverage information when the ruleset changes Depends on D39742 Reviewers: ab, qcolombet, t.p.northover, aditya_nandakumar, rovka Reviewed By: rovka Subscribers: vsk, arsenm, nhaehnle, mgorny, kristof.beyls, javed.absar, igorb, llvm-commits Differential Revision: https://reviews.llvm.org/D39747 llvm-svn: 318356
2017-11-16 00:46:35 +00:00
option(LLVM_ENABLE_GISEL_COV "Enable collection of GlobalISel rule coverage" OFF)
if(LLVM_ENABLE_GISEL_COV)
set(LLVM_GISEL_COV_PREFIX "${CMAKE_BINARY_DIR}/gisel-coverage-" CACHE STRING "Provide a filename prefix to collect the GlobalISel rule coverage")
endif()
[Tablegen] Instrumenting table gen DAGGenISelDAG To help assist in debugging ISEL or to prioritize GlobalISel backend work, this patch adds two more tables to <Target>GenISelDAGISel.inc - one which contains the patterns that are used during selection and the other containing include source location of the patterns Enabled through CMake varialbe LLVM_ENABLE_DAGISEL_COV llvm-svn: 295081
2017-02-14 18:32:41 +00:00
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
# Add path for custom modules
[CMake] Factor out config prefix finding logic See the docs in the new function for details. I think I found every instance of this copy pasted code. Polly could also use it, but currently does something different, so I will save the behavior change for a future revision. We get the shared, non-installed CMake modules following the pattern established in D116472. It might be good to have LLD and Flang also use this, but that would be a functional change and so I leave it as future work. Reviewed By: beanz, lebedev.ri Differential Revision: https://reviews.llvm.org/D116521
2022-01-03 02:25:06 +00:00
list(INSERT CMAKE_MODULE_PATH 0
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
"${CMAKE_CURRENT_SOURCE_DIR}/cmake"
"${CMAKE_CURRENT_SOURCE_DIR}/cmake/modules"
[CMake] Factor out config prefix finding logic See the docs in the new function for details. I think I found every instance of this copy pasted code. Polly could also use it, but currently does something different, so I will save the behavior change for a future revision. We get the shared, non-installed CMake modules following the pattern established in D116472. It might be good to have LLD and Flang also use this, but that would be a functional change and so I leave it as future work. Reviewed By: beanz, lebedev.ri Differential Revision: https://reviews.llvm.org/D116521
2022-01-03 02:25:06 +00:00
"${LLVM_COMMON_CMAKE_UTILS}/Modules"
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
)
# Generate a CompilationDatabase (compile_commands.json file) for our build,
# for use by clang_complete, YouCompleteMe, etc.
set(CMAKE_EXPORT_COMPILE_COMMANDS 1)
[tools] Add option to install binutils symlinks The LLVM tools can be used as a replacement for binutils, in which case it's convenient to create symlinks with the binutils names. Add support for these symlinks in the build system. As with any other llvm tool symlinks, the user can limit the installed symlinks by only adding the desired ones to `LLVM_TOOLCHAIN_TOOLS`. Differential Revision: https://reviews.llvm.org/D39530 llvm-svn: 317272
2017-11-02 21:43:32 +00:00
option(LLVM_INSTALL_BINUTILS_SYMLINKS
"Install symlinks from the binutils tool names to the corresponding LLVM tools." OFF)
[build] Add the ability to create a symlink for lipo Add user enabled option to create lipo with symlink to llvm-lipo Used rL326381 for reference. Differential Revision: https://reviews.llvm.org/D65477 llvm-svn: 367444
2019-07-31 16:46:57 +00:00
option(LLVM_INSTALL_CCTOOLS_SYMLINKS
"Install symlinks from the cctools tool names to the corresponding LLVM tools." OFF)
[CMake] Add option LLVM_FORCE_CREATE_SYMLINKS On Windows we don't create symlinks for the binaries (clang++, clang-cl) since the support requires special setup (group policy settings and you need to know exactly our distribution story). But if you know about these things and have a controlled environment there is a lot of storage to be saved, so let's add a manual opt-in for using symlinks on Windows with LLVM_FORCE_CREATE_SYMLINKS=ON. Reviewed By: phosek Differential Revision: https://reviews.llvm.org/D135578
2022-10-12 10:04:21 +02:00
# By default we use symlinks on Unix platforms and copy binaries on Windows
# If you have the correct setup on Windows you can use this option to enable
# symlinks and save a lot of diskspace.
option(LLVM_USE_SYMLINKS "Use symlinks instead of copying binaries" ${CMAKE_HOST_UNIX})
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
option(LLVM_INSTALL_UTILS "Include utility binaries in the 'install' target." OFF)
option(LLVM_INSTALL_TOOLCHAIN_ONLY "Only include toolchain files in the 'install' target." OFF)
[LLVM] Allow modulemap installation Summary: Currently we can't install the modulemaps provided by LLVM, since they are not structured to support headers generated as part of the build (ex. `llvm/IR/Attributes.gen`). This patch restructures the module maps in order to support installation. Modules containing generated headers are defined in the new `module.extern.modulemap` file, and are referenced from the main `module.modulemap` using `extern module`. There are two versions of the `module.extern.modulemap` file; one used when building and another, `module.install.modulemap`, which is re-named during installation. Users can opt-into module map installation using `-DLLVM_INSTALL_MODULEMAPS=ON`. The default value is `OFF` due to llvm.org/PR31905. Reviewers: rsmith, mehdi_amini, bruno, EricWF Reviewed By: EricWF Subscribers: tschuett, chapuni, mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D53510 llvm-svn: 347420
2018-11-21 20:46:50 +00:00
# Unfortunatly Clang is too eager to search directories for module maps, which can cause the
# installed version of the maps to be found when building LLVM from source. Therefore we turn off
# the installation by default. See llvm.org/PR31905.
option(LLVM_INSTALL_MODULEMAPS "Install the modulemap files in the 'install' target." OFF)
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
option(LLVM_USE_FOLDERS "Enable solution folders in Visual Studio. Disable for Express versions." ON)
if ( LLVM_USE_FOLDERS )
set_property(GLOBAL PROPERTY USE_FOLDERS ON)
endif()
include(VersionFromVCS)
option(LLVM_APPEND_VC_REV
[CMake] Unify scripts for generating VCS headers Previously, there were two different scripts for generating VCS headers: one used by LLVM and one used by Clang and lldb. They were both similar, but different. They were both broken in their own ways, for example the one used by Clang didn't properly handle monorepo resulting in an incorrect version information reported by Clang. This change unifies two the scripts by introducing a new script that's used from both LLVM, Clang and lldb, ensures that the new script supports both monorepo and standalone SVN and Git setups, and removes the old scripts. Differential Revision: https://reviews.llvm.org/D57063 llvm-svn: 353268
2019-02-06 03:51:00 +00:00
"Embed the version control system revision in LLVM" ON)
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
[cmake] Add LLVM_FORCE_VC_REVISION option (#67125) 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.
2023-09-25 14:32:52 +01:00
set(LLVM_FORCE_VC_REVISION
"" CACHE STRING "Force custom VC revision for LLVM_APPEND_VC_REV")
set(LLVM_FORCE_VC_REPOSITORY
"" CACHE STRING "Force custom VC repository for LLVM_APPEND_VC_REV")
LLVM Driver Multicall tool This patch adds an llvm-driver multicall tool that can combine multiple LLVM-based tools. The build infrastructure is enabled for a tool by adding the GENERATE_DRIVER option to the add_llvm_executable CMake call, and changing the tool's main function to a canonicalized tool_name_main format (i.e. llvm_ar_main, clang_main, etc...). As currently implemented llvm-driver contains dsymutil, llvm-ar, llvm-cxxfilt, llvm-objcopy, and clang (if clang is included in the build). llvm-driver can be enabled from builds by setting LLVM_TOOL_LLVM_DRIVER_BUILD=On. There are several limitations in the current implementation, which can be addressed in subsequent patches: (1) the multicall binary cannot currently properly handle multi-dispatch tools. This means symlinking llvm-ranlib to llvm-driver will not properly result in llvm-ar's main being called. (2) the multicall binary cannot be comprised of tools containing conflicting cl::opt options as the global cl::opt option list cannot contain duplicates. These limitations can be addressed in subsequent patches. Differential revision: https://reviews.llvm.org/D109977
2022-06-06 04:25:55 +00:00
option(LLVM_TOOL_LLVM_DRIVER_BUILD "Enables building the llvm multicall tool" OFF)
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
set(PACKAGE_NAME LLVM)
set(PACKAGE_STRING "${PACKAGE_NAME} ${PACKAGE_VERSION}")
Update Bug report URL to Github Issues Although we moved to Github Issues. The bug report message refers to Bugzilla still. This patch tries to update these URLs. Reviewed By: MaskRay, Quuxplusone, jhenderson, libunwind, libc++ Differential Revision: https://reviews.llvm.org/D116351
2022-01-06 17:33:25 +08:00
set(PACKAGE_BUGREPORT "https://github.com/llvm/llvm-project/issues/")
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
set(BUG_REPORT_URL "${PACKAGE_BUGREPORT}" CACHE STRING
"Default URL where bug reports are to be submitted.")
[lldb] Add LLDB_BUG_REPORT_URL macro to allow a different URL for lldb bug 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`.
2024-01-16 10:50:48 -05:00
set(LLDB_BUG_REPORT_URL "${BUG_REPORT_URL}" CACHE STRING
"Default URL where lldb bug reports are to be submitted.")
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
# Configure CPack.
[CMake]Allow user specified CPack Options This should allow downstream vendors to install multiple LLVM distributions in parallel. Should we also patch the default values to allow multiple upstream llvm distribution? Reviewed By: thieta Differential Revision: https://reviews.llvm.org/D138632
2022-12-06 10:55:17 +01:00
if(NOT DEFINED CPACK_PACKAGE_INSTALL_DIRECTORY)
set(CPACK_PACKAGE_INSTALL_DIRECTORY "LLVM")
endif()
if(NOT DEFINED CPACK_PACKAGE_VENDOR)
set(CPACK_PACKAGE_VENDOR "LLVM")
endif()
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
set(CPACK_PACKAGE_VERSION_MAJOR ${LLVM_VERSION_MAJOR})
set(CPACK_PACKAGE_VERSION_MINOR ${LLVM_VERSION_MINOR})
set(CPACK_PACKAGE_VERSION_PATCH ${LLVM_VERSION_PATCH})
set(CPACK_PACKAGE_VERSION ${PACKAGE_VERSION})
set(CPACK_RESOURCE_FILE_LICENSE "${CMAKE_CURRENT_SOURCE_DIR}/LICENSE.TXT")
if(WIN32 AND NOT UNIX)
[CMake]Allow user specified CPack Options This should allow downstream vendors to install multiple LLVM distributions in parallel. Should we also patch the default values to allow multiple upstream llvm distribution? Reviewed By: thieta Differential Revision: https://reviews.llvm.org/D138632
2022-12-06 10:55:17 +01:00
set(CPACK_NSIS_COMPRESSOR "/SOLID lzma \r\n SetCompressorDictSize 32")
if(NOT DEFINED CPACK_PACKAGE_INSTALL_REGISTRY_KEY)
set(CPACK_PACKAGE_INSTALL_REGISTRY_KEY "LLVM")
endif()
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
set(CPACK_PACKAGE_ICON "${CMAKE_CURRENT_SOURCE_DIR}\\\\cmake\\\\nsis_logo.bmp")
set(CPACK_NSIS_MUI_ICON "${CMAKE_CURRENT_SOURCE_DIR}\\\\cmake\\\\nsis_icon.ico")
set(CPACK_NSIS_MUI_UNIICON "${CMAKE_CURRENT_SOURCE_DIR}\\\\cmake\\\\nsis_icon.ico")
set(CPACK_NSIS_MODIFY_PATH "ON")
set(CPACK_NSIS_ENABLE_UNINSTALL_BEFORE_INSTALL "ON")
if( CMAKE_CL_64 )
[CMake]Allow user specified CPack Options This should allow downstream vendors to install multiple LLVM distributions in parallel. Should we also patch the default values to allow multiple upstream llvm distribution? Reviewed By: thieta Differential Revision: https://reviews.llvm.org/D138632
2022-12-06 10:55:17 +01:00
if(NOT DEFINED CPACK_NSIS_INSTALL_ROOT)
set(CPACK_NSIS_INSTALL_ROOT "$PROGRAMFILES64")
endif()
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
endif()
endif()
include(CPack)
# Sanity check our source directory to make sure that we are not trying to
[CMake] Fix typo: "in-tree" -> "in-source" (NFC) Summary: *In-source builds* of LLVM, in which a user invokes `cmake` from within the LLVM source directory, or invokes `cmake -B/path/to/source/dir/of/llvm`, are explicitly checked for and disallowed by LLVM's `CMakeLists.txt`. *In-tree builds*, on the other hand, refer to when the source directories of projects such as Clang are nested within the `llvm/tools` source directory. These are not disallowed, and are in fact a common way of building LLVM and Clang. Revise the comment to match the logic underneath it: it checks for an "in-source build", not an "in-tree build". Reviewers: beanz Reviewed By: beanz Subscribers: mgorny Differential Revision: https://reviews.llvm.org/D38317 llvm-svn: 314348
2017-09-27 21:37:33 +00:00
# generate an in-source build (unless on MSVC_IDE, where it is ok), and to make
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
# sure that we don't have any stray generated files lying around in the tree
# (which would end up getting picked up by header search, instead of the correct
# versions).
[CMake] Allow parent projects to use in-source builds LLVM checks if it is performing an in-source build and then stop the build. However, this check is also triggered if LLVM is being build as part of a parent project, which prevents the parent project itself from using in-source builds. For example, CMake allows a parent project to specify the output of its subproject: add_subdirectory(llvm llvm_build) This tells CMake to conduct an out-tree build of LLVM, which without this patch will still fails because what is being tested is the parent project, not LLVM. This is fixed by using the "CURRENT" variable, which is only concerned by the CMakeLists that is actually bein processed at the moment. Tests: Ran `make check-llvm`. Patch by Henrique Jung <henriquenj_AT_gmail_DOT_com> llvm-svn: 316142
2017-10-19 00:43:48 +00:00
if( CMAKE_CURRENT_SOURCE_DIR STREQUAL CMAKE_CURRENT_BINARY_DIR AND NOT MSVC_IDE )
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
message(FATAL_ERROR "In-source builds are not allowed.
Please create a directory and run cmake from there, passing the path
to this source directory as the last argument.
This process created the file `CMakeCache.txt' and the directory `CMakeFiles'.
Please delete them.")
endif()
string(TOUPPER "${CMAKE_BUILD_TYPE}" uppercase_CMAKE_BUILD_TYPE)
[CMake] Make specifying invalid build type a fatal error (#72021) 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.
2023-11-16 10:32:14 -08:00
option(LLVM_ADDITIONAL_BUILD_TYPES "Additional build types that are allowed to be passed into CMAKE_BUILD_TYPE" "")
set(ALLOWED_BUILD_TYPES DEBUG RELEASE RELWITHDEBINFO MINSIZEREL ${LLVM_ADDITIONAL_BUILD_TYPES})
string (REPLACE ";" "|" ALLOWED_BUILD_TYPES_STRING "${ALLOWED_BUILD_TYPES}")
string (TOUPPER "${ALLOWED_BUILD_TYPES_STRING}" uppercase_ALLOWED_BUILD_TYPES)
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
if (CMAKE_BUILD_TYPE AND
[CMake] Make specifying invalid build type a fatal error (#72021) 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.
2023-11-16 10:32:14 -08:00
NOT uppercase_CMAKE_BUILD_TYPE MATCHES "^(${uppercase_ALLOWED_BUILD_TYPES})$")
message(FATAL_ERROR "Unknown value for CMAKE_BUILD_TYPE: ${CMAKE_BUILD_TYPE}")
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
endif()
[llvm] [cmake] Move LLVM_INSTALL_PACKAGE_DIR top-level to fix llvm-config Move the `LLVM_INSTALL_PACKAGE_DIR` declaration from llvm/cmake/modules directory to the top-level llvm/CMakeLists.txt, in order to fix the regression in `llvm-config --cmakedir` output for installed LLVM. Since the tools directory is processed by CMake prior to llvm/cmake/modules, the llvm-config executable ended up using the variable prior to it being defined and incorrectly used an empty path, resulting in e.g.: $ llvm-config --cmakedir /usr/lib/llvm/16/ With this patch, the path is defined (and therefore the default value is being set) prior to adding the tools subdirectory and llvm-config starts working correctly: $ llvm-config --cmakedir /usr/lib/llvm/16/lib64/cmake/llvm This fixes a regression introduced by D130539. Thanks to Petr Polezhaev for reporting the problem @ https://bugs.gentoo.org/865165 Differential Revision: https://reviews.llvm.org/D131878
2022-08-15 09:50:14 +02:00
# LLVM_INSTALL_PACKAGE_DIR needs to be declared prior to adding the tools
# subdirectory in order to have the value available for llvm-config.
include(GNUInstallPackageDir)
set(LLVM_INSTALL_PACKAGE_DIR "${CMAKE_INSTALL_PACKAGEDIR}/llvm" CACHE STRING
"Path for CMake subdirectory for LLVM (defaults to '${CMAKE_INSTALL_PACKAGEDIR}/llvm')")
[llvm] Use `GNUInstallDirs` to support custom installation dirs This is the patch for LLVM proper in my series for adding GNUInstallDirs support in all project. Additionally: Create a new `CACHE STRING` variable, `LLVM_EXAMPLES_INSTALL_DIR`, to control where the examples are installed on analogy with the other variables. --- This patch supersedes D28234, which tried to do the same thing but hand-rolled without GNUInstallDirs. This patch nearly reverts commit 3 0fc88bf1dc15a72e2d9809d28019d386b7a7cc0, which was a revert of a prior attempt." (I had to add a space here or else Phabricator detects a reference cycle and won't let me do the form submit.) Reviewed By: compnerd Differential Revision: https://reviews.llvm.org/D100810
2021-12-11 01:36:24 +00:00
set(LLVM_TOOLS_INSTALL_DIR "${CMAKE_INSTALL_BINDIR}" CACHE STRING
"Path for binary subdirectory (defaults to '${CMAKE_INSTALL_BINDIR}')")
[CMake] Support overriding binary install directory This patch adds a new option LLVM_TOOLS_INSTALL_DIR which allows customizing the location executables and symlinks get installed to. This adds the functionality provided by autoconf's --bindir flag. This patch is based on patches from and collaboration with Tony Kelman, and replaces http://reviews.llvm.org/D20934. llvm-svn: 272200
2016-06-08 21:19:26 +00:00
mark_as_advanced(LLVM_TOOLS_INSTALL_DIR)
[cmake] Fix typo in LLVM_UTILS_INSTALL_DIR definition. Differential Revision: https://reviews.llvm.org/D41804 llvm-svn: 322959
2018-01-19 17:02:12 +00:00
set(LLVM_UTILS_INSTALL_DIR "${LLVM_TOOLS_INSTALL_DIR}" CACHE STRING
CMake: Add LLVM_UTILS_INSTALL_DIR option Summary: This is like the LLVM_TOOLS_INSTALL_DIR option, but for the utils that are installed when the LLVM_INSTALL_UTILS. This option defaults to 'bin' to remain consistent with the current behavior, but distros may want to install these to libexec/llvm. Reviewers: beanz Reviewed By: beanz Subscribers: llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D30655 llvm-svn: 307150
2017-07-05 12:57:30 +00:00
"Path to install LLVM utilities (enabled by LLVM_INSTALL_UTILS=ON) (defaults to LLVM_TOOLS_INSTALL_DIR)")
[cmake] Fix typo in LLVM_UTILS_INSTALL_DIR definition. Differential Revision: https://reviews.llvm.org/D41804 llvm-svn: 322959
2018-01-19 17:02:12 +00:00
mark_as_advanced(LLVM_UTILS_INSTALL_DIR)
CMake: Add LLVM_UTILS_INSTALL_DIR option Summary: This is like the LLVM_TOOLS_INSTALL_DIR option, but for the utils that are installed when the LLVM_INSTALL_UTILS. This option defaults to 'bin' to remain consistent with the current behavior, but distros may want to install these to libexec/llvm. Reviewers: beanz Reviewed By: beanz Subscribers: llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D30655 llvm-svn: 307150
2017-07-05 12:57:30 +00:00
[llvm] Use `GNUInstallDirs` to support custom installation dirs This is the patch for LLVM proper in my series for adding GNUInstallDirs support in all project. Additionally: Create a new `CACHE STRING` variable, `LLVM_EXAMPLES_INSTALL_DIR`, to control where the examples are installed on analogy with the other variables. --- This patch supersedes D28234, which tried to do the same thing but hand-rolled without GNUInstallDirs. This patch nearly reverts commit 3 0fc88bf1dc15a72e2d9809d28019d386b7a7cc0, which was a revert of a prior attempt." (I had to add a space here or else Phabricator detects a reference cycle and won't let me do the form submit.) Reviewed By: compnerd Differential Revision: https://reviews.llvm.org/D100810
2021-12-11 01:36:24 +00:00
set(LLVM_EXAMPLES_INSTALL_DIR "examples" CACHE STRING
"Path for examples subdirectory (enabled by LLVM_BUILD_EXAMPLES=ON) (defaults to 'examples')")
mark_as_advanced(LLVM_EXAMPLES_INSTALL_DIR)
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
# They are used as destination of target generators.
set(LLVM_RUNTIME_OUTPUT_INTDIR ${CMAKE_CURRENT_BINARY_DIR}/${CMAKE_CFG_INTDIR}/bin)
Revert "[cmake] Use `CMAKE_INSTALL_LIBDIR` too" This reverts commit f7a33090a91015836497c75f173775392ab0304d. Unfortunately this causes a number of failures that didn't show up in my local build.
2022-08-18 22:44:46 -04:00
set(LLVM_LIBRARY_OUTPUT_INTDIR ${CMAKE_CURRENT_BINARY_DIR}/${CMAKE_CFG_INTDIR}/lib${LLVM_LIBDIR_SUFFIX})
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
if(WIN32 OR CYGWIN)
# DLL platform -- put DLLs into bin.
set(LLVM_SHLIB_OUTPUT_INTDIR ${LLVM_RUNTIME_OUTPUT_INTDIR})
else()
set(LLVM_SHLIB_OUTPUT_INTDIR ${LLVM_LIBRARY_OUTPUT_INTDIR})
endif()
# Each of them corresponds to llvm-config's.
set(LLVM_TOOLS_BINARY_DIR ${LLVM_RUNTIME_OUTPUT_INTDIR}) # --bindir
set(LLVM_LIBRARY_DIR ${LLVM_LIBRARY_OUTPUT_INTDIR}) # --libdir
set(LLVM_MAIN_SRC_DIR ${CMAKE_CURRENT_SOURCE_DIR} ) # --src-root
set(LLVM_MAIN_INCLUDE_DIR ${LLVM_MAIN_SRC_DIR}/include ) # --includedir
set(LLVM_BINARY_DIR ${CMAKE_CURRENT_BINARY_DIR} ) # --prefix
Re-Reland "[benchmarks] Move libcxx's fork of google/benchmark and llvm/utils'" This reverts commit b2fbd45d2395f1f6ef39db72b7156724fc101e40. D114922 fixed the reason of the 2nd revert. This patch also re-applies 39e9f5d3685f3cfca0df072928ad96d973704dff. Differential Revision: https://reviews.llvm.org/D112012
2021-12-07 16:46:55 -08:00
[LLVM][CMake][NFC] Resolve FIXME: Rename LLVM_CMAKE_PATH to LLVM_CMAKE_DIR throughout the project 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
2021-09-16 18:27:53 +02:00
# Note: LLVM_CMAKE_DIR does not include generated files
set(LLVM_CMAKE_DIR ${LLVM_MAIN_SRC_DIR}/cmake/modules)
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
set(LLVM_EXAMPLES_BINARY_DIR ${LLVM_BINARY_DIR}/examples)
set(LLVM_INCLUDE_DIR ${CMAKE_CURRENT_BINARY_DIR}/include)
Remove RISCV from LLVM_ALL_TARGETS in CMakeLists.txt It was mistakenly added to that list in D23560 (committed in rL285712). RISCV is an experimental backend and should never have been in that list, I mistakenly interpreted LLVM_ALL_TARGETS as a list of all targets rather than targets to build by default. Unfortunately, because of this the RISCV backend has been building by default when it shouldn't be. This commet adds a description comment, which should help to avoid such mistakes in the future. See my message to llvm-dev for more information and analysis <http://lists.llvm.org/pipermail/llvm-dev/2017-August/116347.html>. Differential Revision: https://reviews.llvm.org/D36538 llvm-svn: 310796
2017-08-13 18:49:33 +00:00
# List of all targets to be built by default:
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
set(LLVM_ALL_TARGETS
AArch64
AMDGPU
ARM
[AVR] Include AVR by default in LLVM builds This was initially committed and promptly reverted in 9059056e273ccc3a236751609e498b4c401eb6ff 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
2020-03-12 19:07:01 +13:00
AVR
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
BPF
Hexagon
[lanai] Make Lanai backend non-experimental Summary: Add Lanai backend to default targets. Discussion of proposal: http://lists.llvm.org/pipermail/llvm-dev/2016-July/102480.html. ISA added in r279149. Reviewers: jyknight, rengolin, eliben, chandlerc Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D22530 llvm-svn: 279498
2016-08-23 01:06:44 +00:00
Lanai
Reland "[CMake][LoongArch] Add LoongArch to LLVM_ALL_TARGETS so it is built by default" This follows the [[ https://discourse.llvm.org/t/rfc-promoting-the-loongarch-backend-from-experimental-to-official/67506/ | RFC ]]. Follow-on commits will add appropriate release notes changes etc. Submit this now and in a minimal form so there is reasonable time before 16.0.0 is branched to resolve any issues arising from e.g. the backend being exposed on different compiler/sanitizer setups. The current builder for LoongArch is on the [[ https://lab.llvm.org/staging/#/builders/236 | staging area ]]. Reviewed By: jyknight, MaskRay, echristo, myhsu, tstellar, arsenm Differential Revision: https://reviews.llvm.org/D141191
2023-01-11 16:35:48 +08:00
LoongArch
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
Mips
MSP430
NVPTX
PowerPC
[RISCV] Re-land r366331 d RISCV to LLVM_ALL_TARGETS *San flagged issues should be now be addressed. llvm-svn: 366399
2019-07-18 04:05:18 +00:00
RISCV
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
Sparc
[SPIR-V] Add SPIRV to LLVM_ALL_TARGETS (reapply) (#123733) This commit promotes the SPIR-V backend from experimental to official status. As a result, SPIR-V will be built by default, simplifying integration and increasing accessibility for downstream projects. Discussion and RFC on Discourse: https://discourse.llvm.org/t/rfc-promoting-spir-v-to-an-official-target/83614 The PR reapplies the original patch https://github.com/llvm/llvm-project/pull/119653 and consecutive https://github.com/llvm/llvm-project/pull/123654, reverted due to buildbot failures.
2025-01-21 12:39:03 +01:00
SPIRV
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
SystemZ
Revert "Revert "[VE] Make VE official"" This reverts commit 27c9e8b45b25614a92539ac6787dbb5670d950b3. Bugs exposed by AddressSanitizer have been reproduced and fixed locally: * commit e37000f3bff384 * commit 435d44bf8ab392
2021-12-02 11:17:47 +01:00
VE
[WebAssembly] Add WebAssembly to LLVM_ALL_TARGETS Summary: After fixing memory leaks in rL343362 and rL343733 the sanitizer builds are clean and we should be good to build by default again. Differential Revision: https://reviews.llvm.org/D52850 llvm-svn: 343746
2018-10-03 23:56:52 +00:00
WebAssembly
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
X86
XCore
)
Allow setting LLVM_EXPERIMENTAL_TARGETS_TO_BUILD to "all" 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
2023-06-27 16:28:08 -07:00
set(LLVM_ALL_EXPERIMENTAL_TARGETS
ARC
CSKY
DirectX
M68k
Xtensa
)
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
# List of targets with JIT support:
set(LLVM_TARGETS_WITH_JIT X86 PowerPC AArch64 ARM Mips SystemZ)
set(LLVM_TARGETS_TO_BUILD "all"
CACHE STRING "Semicolon-separated list of targets to build, or \"all\".")
set(LLVM_EXPERIMENTAL_TARGETS_TO_BUILD ""
Allow setting LLVM_EXPERIMENTAL_TARGETS_TO_BUILD to "all" 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
2023-06-27 16:28:08 -07:00
CACHE STRING "Semicolon-separated list of experimental targets to build, or \"all\".")
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
option(BUILD_SHARED_LIBS
"Build all libraries as shared libraries instead of static" OFF)
option(LLVM_ENABLE_BACKTRACES "Enable embedding backtraces on crash." ON)
if(LLVM_ENABLE_BACKTRACES)
set(ENABLE_BACKTRACES 1)
endif()
build: add option to disable unwind tables The unwind tables (`.eh_frame`, `.arm.extab`) add a significant chunk of data to the final binaries. These should not be needed normally, particularly when exceptions are disabled. This enables shrinking `lldb-server` by ~18% (3 MiB) when built with gold. llvm-svn: 359819
2019-05-02 19:37:26 +00:00
option(LLVM_ENABLE_UNWIND_TABLES "Emit unwind tables for the libraries" ON)
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
option(LLVM_ENABLE_CRASH_OVERRIDES "Enable crash overrides." ON)
if(LLVM_ENABLE_CRASH_OVERRIDES)
set(ENABLE_CRASH_OVERRIDES 1)
endif()
Add cmake option to disable minidumps, default it to off Since crash dumping landed in r268519, May 2016, I have not once seen anyone use an uploaded minidump to debug a compiler crash. Therefore, I'm turning this off by default. The dumps clutter up user and buildbot temp directories. Each file is only about 56KB, but it adds up. In the context of clang, the extra line about the minidump confuses users, when what we really want from them is the pre-processed source code. llvm-svn: 340185
2018-08-20 16:49:54 +00:00
option(LLVM_ENABLE_CRASH_DUMPS "Turn on memory dumps on crashes. Currently only implemented on Windows." OFF)
[DLCov 1/5] Add CMake option for enhanced debug line coverage tracking (#107278) This is part of a series of patches that tries to improve DILocation bug detection in Debugify. This first patch adds the necessary CMake flag to LLVM and a variable defined by that flag to LLVM's config header, allowing the next patch to track information without affecting normal builds. This series of patches adds a "DebugLoc coverage tracking" feature, that inserts conditionally-compiled tracking information into DebugLocs (and by extension, to Instructions), which is used by Debugify to provide more accurate and detailed coverage reports. When enabled, this features tracks whether and why we have intentionally dropped a DebugLoc, allowing Debugify to ignore false positives. An optional additional feature allows also storing a stack trace of the point where a DebugLoc was unintentionally dropped/not generated, which is used to make fixing detected errors significantly easier. The goal of these features is to provide useful tools for developers to fix existing DebugLoc errors and allow reliable detection of regressions by either manual inspection or an automated script.
2024-10-08 18:15:46 +01:00
set(LLVM_ENABLE_DEBUGLOC_COVERAGE_TRACKING "DISABLED" CACHE STRING
"Enhance Debugify's line number coverage tracking; enabling this is ABI-breaking. Can be DISABLED, or COVERAGE.")
set_property(CACHE LLVM_ENABLE_DEBUGLOC_COVERAGE_TRACKING PROPERTY STRINGS DISABLED COVERAGE)
[NFC][KeyInstr] Add (LLVM_)EXPERIMENTAL_KEY_INSTRUCTIONS (cmake/)definition (#131344) Key Instructions will start development behind a compile time flag to avoid passing on the increased memory usage to all debug builds. We're working on improving DILocation memory characteristics simultaneously; once that work lands we can remove `EXPERIMENTAL_KEY_INSTRUCTIONS`. This patch doesn't add any code, it's just so we can get the SIE buildbot building with the new option right away.
2025-03-17 11:32:59 +00:00
option(LLVM_EXPERIMENTAL_KEY_INSTRUCTIONS
"Add additional fields to DILocations to support Key Instructions" OFF)
[Support] Allow configuring the preferred type of slashes on Windows 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
2021-10-13 12:18:32 +00:00
set(WINDOWS_PREFER_FORWARD_SLASH_DEFAULT OFF)
if (MINGW)
# Cygwin doesn't identify itself as Windows, and thus gets path::Style::posix
# as native path style, regardless of what this is set to.
set(WINDOWS_PREFER_FORWARD_SLASH_DEFAULT ON)
endif()
option(LLVM_WINDOWS_PREFER_FORWARD_SLASH "Prefer path names with forward slashes on Windows." ${WINDOWS_PREFER_FORWARD_SLASH_DEFAULT})
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
option(LLVM_ENABLE_FFI "Use libffi to call external functions from the interpreter" OFF)
set(FFI_LIBRARY_DIR "" CACHE PATH "Additional directory, where CMake should search for libffi.so")
set(FFI_INCLUDE_DIR "" CACHE PATH "Additional directory, where CMake should search for ffi.h or ffi/ffi.h")
set(LLVM_TARGET_ARCH "host"
CACHE STRING "Set target to use for LLVM JIT or use \"host\" for automatic detection.")
CMake: Turn LLVM_ENABLE_LIBXML2 into a tri-state option In addition to the current ON and OFF options, this adds the FORCE_ON option, which causes a configuration error if libxml2 cannot be used. Differential revision: https://reviews.llvm.org/D40050 llvm-svn: 318209
2017-11-14 22:32:49 +00:00
set(LLVM_ENABLE_LIBXML2 "ON" CACHE STRING "Use libxml2 if available. Can be ON, OFF, or FORCE_ON")
Implement parsing and writing of a single xml manifest file. Summary: Implement parsing and writing of a single xml manifest file. Subscribers: mgorny, llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D35425 llvm-svn: 308679
2017-07-20 21:42:04 +00:00
Add an option to disable libedit Summary: This should provide the function similar to `--disable-libedit` with the autotools build system, which seems to be missing from the commit (r200595) that adds this. Reviewers: pcc, beanz Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D26550 llvm-svn: 287293
2016-11-18 01:25:49 +00:00
option(LLVM_ENABLE_LIBEDIT "Use libedit if available." ON)
[llvm-exegesis] Add a flag to disable libpfm even if present. Summary: Fixes PR37053. Reviewers: uabelho, gchatelet Subscribers: mgorny, tschuett, llvm-commits Differential Revision: https://reviews.llvm.org/D45436 llvm-svn: 329781
2018-04-11 07:32:43 +00:00
option(LLVM_ENABLE_LIBPFM "Use libpfm for performance counters if available." ON)
[SystemZ/ZOS] Additions to the build system. 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
2020-07-09 14:17:33 +02:00
# On z/OS, threads cannot be used because TLS is not supported.
if (CMAKE_SYSTEM_NAME MATCHES "OS390")
option(LLVM_ENABLE_THREADS "Use threads if available." OFF)
else()
option(LLVM_ENABLE_THREADS "Use threads if available." ON)
endif()
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
CMake: Turn LLVM_ENABLE_ZLIB into a tri-state option 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
2020-03-12 15:51:40 -07:00
set(LLVM_ENABLE_ZLIB "ON" CACHE STRING "Use zlib for compression/decompression if available. Can be ON, OFF, or FORCE_ON")
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
[llvm] add zstd to `llvm::compression` namespace - 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
2022-07-19 10:54:35 -07:00
set(LLVM_ENABLE_ZSTD "ON" CACHE STRING "Use zstd for compression/decompression if available. Can be ON, OFF, or FORCE_ON")
use LLVM_USE_STATIC_ZSTD removes LLVM_PREFER_STATIC_ZSTD in favor of using a LLVM_USE_STATIC_ZSTD Reviewed By: phosek Differential Revision: https://reviews.llvm.org/D133222
2022-09-02 21:00:07 +00:00
set(LLVM_USE_STATIC_ZSTD FALSE CACHE BOOL "Use static version of zstd. Can be TRUE, FALSE")
tweak zstd behavior in cmake and llvm config for better testing 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
2022-09-01 07:49:42 -07:00
[llvm] [Debuginfod] Disable CURL by default. Sets LLVM_ENABLE_CURL to OFF by default to avoid accidental inclusion of libcurl in builds which do not override the default. Reviewed By: thakis Differential Revision: https://reviews.llvm.org/D115500
2021-12-13 17:39:01 +00:00
set(LLVM_ENABLE_CURL "OFF" CACHE STRING "Use libcurl for the HTTP client if available. Can be ON, OFF, or FORCE_ON")
[llvm] [Support] Add CURL HTTP Client. Provides an implementation of `HTTPClient` that wraps libcurl. Reviewed By: dblaikie Differential Revision: https://reviews.llvm.org/D112753
2021-12-02 19:33:04 +00:00
Revert "Enable logf128 constant folding for hosts with 128bit long double (#104929)" ConstantFolding behaves differently depending on host's `HAS_IEE754_FLOAT128`. LLVM should not change the behavior depending on host configurations. This reverts commit 14c7e4a1844904f3db9b2dc93b722925a8c66b27. (llvmorg-20-init-3262-g14c7e4a18449 and llvmorg-20-init-3498-g001e423ac626)
2024-08-25 08:17:48 +09:00
set(LLVM_HAS_LOGF128 "OFF" CACHE STRING "Use logf128 to constant fold fp128 logarithm calls. Can be ON, OFF, or FORCE_ON")
[llvm] [Debuginfod] Add cpp-httplib optional dependency. Adds optional dependency on cpp-httplib, a lightweight header-only HTTP server. Reviewed By: phosek Differential Revision: https://reviews.llvm.org/D113218
2022-07-06 18:39:59 +00:00
set(LLVM_ENABLE_HTTPLIB "OFF" CACHE STRING "Use cpp-httplib HTTP server library if available. Can be ON, OFF, or FORCE_ON")
Moved everything SMT-related to LLVM and updated the cmake scripts. Differential Revision: https://reviews.llvm.org/D54978 llvm-svn: 356929
2019-03-25 17:47:45 +00:00
set(LLVM_Z3_INSTALL_DIR "" CACHE STRING "Install directory of the Z3 solver.")
option(LLVM_ENABLE_Z3_SOLVER
"Enable Support for the Z3 constraint solver in LLVM."
${LLVM_ENABLE_Z3_SOLVER_DEFAULT}
)
if (LLVM_ENABLE_Z3_SOLVER)
Bump required minimal Z3 version from 4.7.1 to 4.8.9 (#96682) https://discourse.llvm.org/t/bump-minimal-z3-requirements-from-4-7-1-to-4-8-9/79664 This supposed to unblock #95128 and #95129.
2024-06-26 17:53:16 +02:00
find_package(Z3 4.8.9)
[NFC] Remove trailing whitespace in llvm/CMakeLists.txt Differential Revision: https://reviews.llvm.org/D93234
2020-12-14 17:45:44 +00:00
Change CMake so that we only look for Z3 when LLVM_ENABLE_Z3_SOLVER is enabled Reviewers: mikhail.ramalho Reviewed By: mikhail.ramalho Subscribers: mehdi_amini, mgorny, mikhail.ramalho, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D75544
2020-06-06 16:18:52 -04:00
if (LLVM_Z3_INSTALL_DIR)
if (NOT Z3_FOUND)
Bump required minimal Z3 version from 4.7.1 to 4.8.9 (#96682) https://discourse.llvm.org/t/bump-minimal-z3-requirements-from-4-7-1-to-4-8-9/79664 This supposed to unblock #95128 and #95129.
2024-06-26 17:53:16 +02:00
message(FATAL_ERROR "Z3 >= 4.8.9 has not been found in LLVM_Z3_INSTALL_DIR: ${LLVM_Z3_INSTALL_DIR}.")
Change CMake so that we only look for Z3 when LLVM_ENABLE_Z3_SOLVER is enabled Reviewers: mikhail.ramalho Reviewed By: mikhail.ramalho Subscribers: mehdi_amini, mgorny, mikhail.ramalho, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D75544
2020-06-06 16:18:52 -04:00
endif()
endif()
[NFC] Remove trailing whitespace in llvm/CMakeLists.txt Differential Revision: https://reviews.llvm.org/D93234
2020-12-14 17:45:44 +00:00
Moved everything SMT-related to LLVM and updated the cmake scripts. Differential Revision: https://reviews.llvm.org/D54978 llvm-svn: 356929
2019-03-25 17:47:45 +00:00
if (NOT Z3_FOUND)
message(FATAL_ERROR "LLVM_ENABLE_Z3_SOLVER cannot be enabled when Z3 is not available.")
endif()
set(LLVM_WITH_Z3 1)
endif()
Change CMake so that we only look for Z3 when LLVM_ENABLE_Z3_SOLVER is enabled Reviewers: mikhail.ramalho Reviewed By: mikhail.ramalho Subscribers: mehdi_amini, mgorny, mikhail.ramalho, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D75544
2020-06-06 16:18:52 -04:00
set(LLVM_ENABLE_Z3_SOLVER_DEFAULT "${Z3_FOUND}")
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
if( LLVM_TARGETS_TO_BUILD STREQUAL "all" )
set( LLVM_TARGETS_TO_BUILD ${LLVM_ALL_TARGETS} )
endif()
Allow setting LLVM_EXPERIMENTAL_TARGETS_TO_BUILD to "all" 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
2023-06-27 16:28:08 -07:00
if(LLVM_EXPERIMENTAL_TARGETS_TO_BUILD STREQUAL "all")
set(LLVM_EXPERIMENTAL_TARGETS_TO_BUILD ${LLVM_ALL_EXPERIMENTAL_TARGETS})
endif()
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
set(LLVM_TARGETS_TO_BUILD
${LLVM_TARGETS_TO_BUILD}
${LLVM_EXPERIMENTAL_TARGETS_TO_BUILD})
list(REMOVE_DUPLICATES LLVM_TARGETS_TO_BUILD)
[SystemZ/ZOS] Additions to the build system. (#74730) This change extend the CMake files with the necessary additions to build LLVM for z/OS.
2023-12-07 15:04:56 -05:00
if (NOT CMAKE_SYSTEM_NAME MATCHES "OS390")
option(LLVM_ENABLE_PIC "Build Position-Independent Code" ON)
endif()
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
option(LLVM_ENABLE_MODULES "Compile with C++ modules enabled." OFF)
[CMake] Introduce a LLVM_ENABLE_LOCAL_SUBMODULE_VISIBILITY flag. On Darwin it is currently impossible to build LLVM with modules because the Darwin system module map is not compatible with -fmodules-local-submodule-visibility at this point in time. This patch makes the flag optional and off by default on Darwin so it becomes possible to build LLVM with modules again. http://reviews.llvm.org/D21827 rdar://problem/27019000 llvm-svn: 274196
2016-06-30 01:46:49 +00:00
if(${CMAKE_SYSTEM_NAME} MATCHES "Darwin")
[CMake] Add an LLVM_ENABLE_MODULE_DEBUGGING flag for building with -gmodules. This flag is only effective in builds with debug info and modules. The default is On for Darwin only. rdar://problem/27019000 llvm-svn: 274244
2016-06-30 17:15:44 +00:00
option(LLVM_ENABLE_MODULE_DEBUGGING "Compile with -gmodules." ON)
[CMake] Introduce a LLVM_ENABLE_LOCAL_SUBMODULE_VISIBILITY flag. On Darwin it is currently impossible to build LLVM with modules because the Darwin system module map is not compatible with -fmodules-local-submodule-visibility at this point in time. This patch makes the flag optional and off by default on Darwin so it becomes possible to build LLVM with modules again. http://reviews.llvm.org/D21827 rdar://problem/27019000 llvm-svn: 274196
2016-06-30 01:46:49 +00:00
else()
[CMake] Add an LLVM_ENABLE_MODULE_DEBUGGING flag for building with -gmodules. This flag is only effective in builds with debug info and modules. The default is On for Darwin only. rdar://problem/27019000 llvm-svn: 274244
2016-06-30 17:15:44 +00:00
option(LLVM_ENABLE_MODULE_DEBUGGING "Compile with -gmodules." OFF)
[CMake] Introduce a LLVM_ENABLE_LOCAL_SUBMODULE_VISIBILITY flag. On Darwin it is currently impossible to build LLVM with modules because the Darwin system module map is not compatible with -fmodules-local-submodule-visibility at this point in time. This patch makes the flag optional and off by default on Darwin so it becomes possible to build LLVM with modules again. http://reviews.llvm.org/D21827 rdar://problem/27019000 llvm-svn: 274196
2016-06-30 01:46:49 +00:00
endif()
Reland [lldb][cmake] Also use local submodule visibility on Darwin 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
2020-04-27 14:58:50 +02:00
option(LLVM_ENABLE_LOCAL_SUBMODULE_VISIBILITY "Compile with -fmodules-local-submodule-visibility." ON)
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
option(LLVM_ENABLE_LIBCXX "Use libc++ if available." OFF)
[CMake] Add option to link LLVM/subproject executables against LLVM libc 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
2023-05-28 02:34:30 +00:00
option(LLVM_ENABLE_LLVM_LIBC "Set to on to link all LLVM executables against LLVM libc, assuming it is accessible by the host compiler." OFF)
Add support in CMake to statically link the C++ standard library. It is sometimes useful to have the C++ standard library linked into the assembly when compiling clang, particularly when distributing a compiler onto systems that don't have a copy of stdlibc++ or libc++ installed. This functionality should work with either GCC or Clang as the host compiler, though statically linking libc++ (as may be required for licensing purposes) is only possible if the host compiler is Clang with a copy of libc++ available. Differential Revision: https://reviews.llvm.org/D65603 llvm-svn: 368907
2019-08-14 19:55:59 +00:00
option(LLVM_STATIC_LINK_CXX_STDLIB "Statically link the standard library." OFF)
Add LLVM_ENABLE_LLD option to use LLD as C/C++ linker. Differential revision: https://reviews.llvm.org/D22896 llvm-svn: 277093
2016-07-29 00:46:13 +00:00
option(LLVM_ENABLE_LLD "Use lld as C and C++ linker." OFF)
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
option(LLVM_ENABLE_PEDANTIC "Compile with pedantic enabled." ON)
option(LLVM_ENABLE_WERROR "Fail and stop if a warning is triggered." OFF)
[dump] Make LLVM_ENABLE_DUMP independent, and move to llvm-config.h Summary: Make LLVM_ENABLE_DUMP independent LLVM_ENABLE_ASSERTIONS, move it to llvm-config.h, and update description. Differential Revision: https://reviews.llvm.org/D38406 llvm-svn: 320111
2017-12-07 22:55:40 +00:00
option(LLVM_ENABLE_DUMP "Enable dump functions even when assertions are disabled" OFF)
Add a cmake flag to turn `llvm_unreachable()` into builtin_trap() when assertions are disabled This re-lands 6316129e066e after fixing the condition logic. The new flag seems to not be working yet on Windows, where the builtin trap isn't "no return". Reviewed By: dexonsmith Differential Revision: https://reviews.llvm.org/D121750
2022-03-17 22:19:33 +00:00
option(LLVM_UNREACHABLE_OPTIMIZE "Optimize llvm_unreachable() as undefined behavior (default), guaranteed trap when OFF" ON)
Reverting r315590; it did not include changes for llvm-tblgen, which is causing link errors for several people. Error LNK2019 unresolved external symbol "public: void __cdecl `anonymous namespace'::MatchableInfo::dump(void)const " (?dump@MatchableInfo@?A0xf4f1c304@@QEBAXXZ) referenced in function "public: void __cdecl `anonymous namespace'::AsmMatcherEmitter::run(class llvm::raw_ostream &)" (?run@AsmMatcherEmitter@?A0xf4f1c304@@QEAAXAEAVraw_ostream@llvm@@@Z) llvm-tblgen D:\llvm\2017\utils\TableGen\AsmMatcherEmitter.obj 1 llvm-svn: 315854
2017-10-15 14:32:27 +00:00
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
if( NOT uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG" )
option(LLVM_ENABLE_ASSERTIONS "Enable assertions" OFF)
else()
option(LLVM_ENABLE_ASSERTIONS "Enable assertions" ON)
endif()
Unify XDEBUG and EXPENSIVE_CHECKS (into the latter), and add an option to the cmake build to enable them. Summary: Historically, we had a switch in the Makefiles for turning on "expensive checks". This has never been ported to the cmake build, but the (dead-ish) code is still around. This will also make it easier to turn it on in buildbots. Reviewers: chandlerc Subscribers: jyknight, mzolotukhin, RKSimon, gberry, llvm-commits Differential Revision: http://reviews.llvm.org/D19723 llvm-svn: 268050
2016-04-29 15:22:48 +00:00
Cleanup some problems with LLVM_ENABLE_DUMP in release builds, and always set LLVM_ENABLE_DUMP=ON for +Asserts builds. Differential Revision: https://reviews.llvm.org/D38306 llvm-svn: 314346
2017-09-27 21:19:56 +00:00
option(LLVM_ENABLE_EXPENSIVE_CHECKS "Enable expensive checks" OFF)
CMake: Add option to set LLVM_ENABLE_DUMP Differential Revision: https://reviews.llvm.org/D38267 llvm-svn: 314186
2017-09-26 02:36:58 +00:00
[TypeSize] Allow returning scalable size in implicit conversion to uint64_t 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
2020-03-13 09:13:34 +00:00
# While adding scalable vector support to LLVM, we temporarily want to
[SVE] Make VectorType::getNumElements() complain for scalable vectors 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
2020-04-23 09:52:49 -07:00
# allow an implicit conversion of TypeSize to uint64_t, and to allow
# code to get the fixed number of elements from a possibly scalable vector.
# This CMake flag enables a more strict mode where it asserts that the type
# is not a scalable vector type.
[TypeSize] Allow returning scalable size in implicit conversion to uint64_t 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
2020-03-13 09:13:34 +00:00
#
# Enabling this flag makes it easier to find cases where the compiler makes
# assumptions on the size being 'fixed size', when building tests for
# SVE/SVE2 or other scalable vector architectures.
[ValueTypes] Add EVT::isFixedLengthVector 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
2020-03-18 16:51:45 +00:00
option(LLVM_ENABLE_STRICT_FIXED_SIZE_VECTORS
[SVE] Make VectorType::getNumElements() complain for scalable vectors 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
2020-04-23 09:52:49 -07:00
"Enable assertions that type is not scalable in implicit conversion from TypeSize to uint64_t and calls to getNumElements" OFF)
[TypeSize] Allow returning scalable size in implicit conversion to uint64_t 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
2020-03-13 09:13:34 +00:00
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
set(LLVM_ABI_BREAKING_CHECKS "WITH_ASSERTS" CACHE STRING
"Enable abi-breaking checks. Can be WITH_ASSERTS, FORCE_ON or FORCE_OFF.")
Bump minimum toolchain version Summary: The RFC on moving past C++11 got good traction: http://lists.llvm.org/pipermail/llvm-dev/2019-January/129452.html This patch therefore bumps the toolchain versions according to our policy: llvm.org/docs/DeveloperPolicy.html#toolchain Subscribers: mgorny, jkorous, dexonsmith, llvm-commits, mehdi_amini, jyknight, rsmith, chandlerc, smeenai, hans, reames, lattner, lhames, erichkeane Differential Revision: https://reviews.llvm.org/D57264 llvm-svn: 353374
2019-02-07 05:20:00 +00:00
option(LLVM_FORCE_USE_OLD_TOOLCHAIN
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
"Set to ON to force using an old, unsupported host toolchain." OFF)
[build] Add LLVM_LOCAL_RPATH which can set an rpath on just unit test binaries 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
2020-05-26 06:23:57 -04:00
set(LLVM_LOCAL_RPATH "" CACHE FILEPATH
"If set, an absolute path added as rpath on binaries that do not already contain an executable-relative rpath.")
Bump minimum toolchain version Summary: The RFC on moving past C++11 got good traction: http://lists.llvm.org/pipermail/llvm-dev/2019-January/129452.html This patch therefore bumps the toolchain versions according to our policy: llvm.org/docs/DeveloperPolicy.html#toolchain Subscribers: mgorny, jkorous, dexonsmith, llvm-commits, mehdi_amini, jyknight, rsmith, chandlerc, smeenai, hans, reames, lattner, lhames, erichkeane Differential Revision: https://reviews.llvm.org/D57264 llvm-svn: 353374
2019-02-07 05:20:00 +00:00
option(LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN
"Set to ON to only warn when using a toolchain which is about to be deprecated, instead of emitting an error." OFF)
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
option(LLVM_USE_INTEL_JITEVENTS
"Use Intel JIT API to inform Intel(R) VTune(TM) Amplifier XE 2011 about JIT code"
OFF)
if( LLVM_USE_INTEL_JITEVENTS )
# Verify we are on a supported platform
if( NOT CMAKE_SYSTEM_NAME MATCHES "Windows" AND NOT CMAKE_SYSTEM_NAME MATCHES "Linux" )
message(FATAL_ERROR
"Intel JIT API support is available on Linux and Windows only.")
endif()
endif( LLVM_USE_INTEL_JITEVENTS )
option(LLVM_USE_OPROFILE
"Use opagent JIT interface to inform OProfile about JIT code" OFF)
option(LLVM_EXTERNALIZE_DEBUGINFO
"Generate dSYM files and strip executables and libraries (Darwin Only)" OFF)
[cmake] Build executables with -no_exported_symbols when building Apple toolchain (#87684) Building the Apple way turns off plugin support, meaning we don't need to export unloadable symbols from all executables. While deadstripping effects aren't expected to change, enabling this across all tools prevents the creation of export tries. This saves us ~3.5 MB in just the universal build of `clang`.
2024-04-05 14:41:20 -07:00
option(LLVM_ENABLE_EXPORTED_SYMBOLS_IN_EXECUTABLES
"Preserve exported symbols in executables" ON)
[CMake] Accept ENTITLEMENTS in add_llvm_executable and llvm_codesign Summary: Allow code-signing with entitlements. FORCE may be used to avoid an error when replacing existing signatures. Reviewers: beanz, bogner Reviewed By: beanz Subscribers: mgorny, llvm-commits, lldb-commits Differential Revision: https://reviews.llvm.org/D54443 llvm-svn: 347068
2018-11-16 18:10:36 +00:00
set(LLVM_CODESIGNING_IDENTITY "" CACHE STRING
"Sign executables and dylibs with the given identity or skip if empty (Darwin Only)")
[CMake] Teach the build system to codesign built products Automatically codesign all executables and dynamic libraries if a codesigning identity is given (via LLVM_CODESIGNING_IDENTITY). This option is darwin only for now. Also update platforms/iOS.cmake to pick up the right versions of codesign and codesign_allocate. llvm-svn: 336708
2018-07-10 17:32:48 +00:00
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
# If enabled, verify we are on a platform that supports oprofile.
if( LLVM_USE_OPROFILE )
if( NOT CMAKE_SYSTEM_NAME MATCHES "Linux" )
message(FATAL_ERROR "OProfile support is available on Linux only.")
endif( NOT CMAKE_SYSTEM_NAME MATCHES "Linux" )
endif( LLVM_USE_OPROFILE )
Add PerfJITEventListener for perf profiling support. This new JIT event listener supports generating profiling data for the linux 'perf' profiling tool, allowing it to generate function and instruction level profiles. Currently this functionality is not enabled by default, but must be enabled with LLVM_USE_PERF=yes. Given that the listener has no dependencies, it might be sensible to enable by default once the initial issues have been shaken out. I followed existing precedent in registering the listener by default in lli. Should there be a decision to enable this by default on linux, that should probably be changed. Please note that until https://reviews.llvm.org/D47343 is resolved, using this functionality with mcjit rather than orcjit will not reliably work. Disregarding the previous comment, here's an example: $ cat /tmp/expensive_loop.c bool stupid_isprime(uint64_t num) { if (num == 2) return true; if (num < 1 || num % 2 == 0) return false; for(uint64_t i = 3; i < num / 2; i+= 2) { if (num % i == 0) return false; } return true; } int main(int argc, char **argv) { int numprimes = 0; for (uint64_t num = argc; num < 100000; num++) { if (stupid_isprime(num)) numprimes++; } return numprimes; } $ clang -ggdb -S -c -emit-llvm /tmp/expensive_loop.c -o /tmp/expensive_loop.ll $ perf record -o perf.data -g -k 1 ./bin/lli -jit-kind=mcjit /tmp/expensive_loop.ll 1 $ perf inject --jit -i perf.data -o perf.jit.data $ perf report -i perf.jit.data - 92.59% lli jitted-5881-2.so [.] stupid_isprime stupid_isprime main llvm::MCJIT::runFunction llvm::ExecutionEngine::runFunctionAsMain main __libc_start_main 0x4bf6258d4c544155 + 0.85% lli ld-2.27.so [.] do_lookup_x And line-level annotations also work: │ for(uint64_t i = 3; i < num / 2; i+= 2) { │1 30: movq $0x3,-0x18(%rbp) 0.03 │1 38: mov -0x18(%rbp),%rax 0.03 │ mov -0x10(%rbp),%rcx │ shr $0x1,%rcx 3.63 │ ┌──cmp %rcx,%rax │ ├──jae 6f │ │ if (num % i == 0) 0.03 │ │ mov -0x10(%rbp),%rax │ │ xor %edx,%edx 89.00 │ │ divq -0x18(%rbp) │ │ cmp $0x0,%rdx 0.22 │ │↓ jne 5f │ │ return false; │ │ movb $0x0,-0x1(%rbp) │ │↓ jmp 73 │ │ } 3.22 │1 5f:│↓ jmp 61 │ │ for(uint64_t i = 3; i < num / 2; i+= 2) { Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D44892 llvm-svn: 337789
2018-07-24 00:54:06 +00:00
option(LLVM_USE_PERF
"Use perf JIT interface to inform perf about JIT code" OFF)
# If enabled, verify we are on a platform that supports perf.
if( LLVM_USE_PERF )
if( NOT CMAKE_SYSTEM_NAME MATCHES "Linux" )
message(FATAL_ERROR "perf support is available on Linux only.")
endif( NOT CMAKE_SYSTEM_NAME MATCHES "Linux" )
endif( LLVM_USE_PERF )
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
set(LLVM_USE_SANITIZER "" CACHE STRING
"Define the sanitizer used to build binaries and tests.")
[CMake] Make optimizing sanitizer builds optional This behavior has been the default for a long time, so the default value is On, however this can make it difficult to debug sanitizer failures, so we should have an option to turn it off. llvm-svn: 332628
2018-05-17 16:55:29 +00:00
option(LLVM_OPTIMIZE_SANITIZED_BUILDS "Pass -O1 on debug sanitizer builds" ON)
[cmake] Add LLVM_UBSAN_FLAGS, to allow overriding UBSan flags 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
2020-10-14 19:09:50 -07:00
set(LLVM_UBSAN_FLAGS
"-fsanitize=undefined -fno-sanitize=vptr,function -fno-sanitize-recover=all"
CACHE STRING
"Compile flags set to enable UBSan. Only used if LLVM_USE_SANITIZER contains 'Undefined'.")
[cmake] Allow building fuzzers with OSS-Fuzz flags. Reviewers: kcc, bogner Reviewed By: bogner Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D38858 llvm-svn: 315629
2017-10-12 21:58:41 +00:00
set(LLVM_LIB_FUZZING_ENGINE "" CACHE PATH
"Path to fuzzing library for linking with fuzz targets")
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
option(LLVM_USE_SPLIT_DWARF
[CMake][NFC] Add comment about new `--gdb-index` option used with `-gsplit-dwarf` Follow-up of https://reviews.llvm.org/D108776
2021-08-30 12:32:20 +03:00
"Use -gsplit-dwarf when compiling llvm and --gdb-index when linking." OFF)
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
# Define an option controlling whether we should build for 32-bit on 64-bit
# platforms, where supported.
[AIX] Improve 32/64-bit build configuration 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
2020-02-20 15:39:16 -05:00
if( CMAKE_SIZEOF_VOID_P EQUAL 8 AND NOT (WIN32 OR ${CMAKE_SYSTEM_NAME} MATCHES "AIX"))
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
# TODO: support other platforms and toolchains.
option(LLVM_BUILD_32_BITS "Build 32 bits executables and libraries." OFF)
endif()
# Define the default arguments to use with 'lit', and an option for the user to
# override.
set(LIT_ARGS_DEFAULT "-sv")
if (MSVC_IDE OR XCODE)
set(LIT_ARGS_DEFAULT "${LIT_ARGS_DEFAULT} --no-progress-bar")
endif()
[LIT] Added an option to llvm-lit to emit the necessary test coverage data, 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
2023-07-26 16:46:09 +05:30
if(LLVM_INDIVIDUAL_TEST_COVERAGE)
set(LIT_ARGS_DEFAULT "${LIT_ARGS_DEFAULT} --per-test-coverage")
endif()
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
set(LLVM_LIT_ARGS "${LIT_ARGS_DEFAULT}" CACHE STRING "Default options for lit")
# On Win32 hosts, provide an option to specify the path to the GnuWin32 tools.
if( WIN32 AND NOT CYGWIN )
set(LLVM_LIT_TOOLS_DIR "" CACHE PATH "Path to GnuWin32 tools")
endif()
[CMake] Allow setting the location of host tools with LLVM_NATIVE_TOOL_DIR This avoids having to specify the location of all individual tools. In current builds, one may want to specify LLVM_TABLEGEN, CLANG_TABLEGEN, LLDB_TABLEGEN, LLVM_CONFIG_PATH, CLANG_PSEUDO_GEN and CLANG_TIDY_CONFUSABLE_CHARS_GEN; specifying just the base directory containing all of them is much more convenient. Factorize the code for setting up use of a tool that is used during the build (which either is newly built in the same build, or built in a separate nested cmake build - when cross compiling or when e.g. optimized tablegen is requested - or used from an existing prebuilt binary). Differential Revision: https://reviews.llvm.org/D131052
2022-08-02 14:53:36 +03:00
set(LLVM_NATIVE_TOOL_DIR "" CACHE PATH "Path to a directory containing prebuilt matching native tools (such as llvm-tblgen)")
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
[Support] Vendor rpmalloc in-tree and use it for the Windows 64-bit release (#91862) ### Context We have a longstanding performance issue on Windows, where to this day, the default heap allocator is still lockfull. With the number of cores increasing, building and using LLVM with the default Windows heap allocator is sub-optimal. Notably, the ThinLTO link times with LLD are extremely long, and increase proportionally with the number of cores in the machine. In https://github.com/llvm/llvm-project/commit/a6a37a2fcd2a8048a75bd0d8280497ed89d73224, I introduced the ability build LLVM with several popular lock-free allocators. Downstream users however have to build their own toolchain with this option, and building an optimal toolchain is a bit tedious and long. Additionally, LLVM is now integrated into Visual Studio, which AFAIK re-distributes the vanilla LLVM binaries/installer. The point being that many users are impacted and might not be aware of this problem, or are unable to build a more optimal version of the toolchain. The symptom before this PR is that most of the CPU time goes to the kernel (darker blue) when linking with ThinLTO: ![16c_ryzen9_windows_heap](https://github.com/llvm/llvm-project/assets/37383324/86c3f6b9-6028-4c1a-ba60-a2fa3876fba7) With this PR, most time is spent in user space (light blue): ![16c_ryzen9_rpmalloc](https://github.com/llvm/llvm-project/assets/37383324/646b88f3-5b6d-485d-a2e4-15b520bdaf5b) On higher core count machines, before this PR, the CPU usage becomes pretty much flat because of contention: <img width="549" alt="VM_176_windows_heap" src="https://github.com/llvm/llvm-project/assets/37383324/f27d5800-ee02-496d-a4e7-88177e0727f0"> With this PR, similarily most CPU time is now used: <img width="549" alt="VM_176_with_rpmalloc" src="https://github.com/llvm/llvm-project/assets/37383324/7d4785dd-94a7-4f06-9b16-aaa4e2e505c8"> ### Changes in this PR The avenue I've taken here is to vendor/re-licence rpmalloc in-tree, and use it when building the Windows 64-bit release. Given the permissive rpmalloc licence, prior discussions with the LLVM foundation and @lattner suggested this vendoring. Rpmalloc's author (@mjansson) kindly agreed to ~~donate~~ re-licence the rpmalloc code in LLVM (please do correct me if I misinterpreted our past communications). I've chosen rpmalloc because it's small and gives the best value overall. The source code is only 4 .c files. Rpmalloc is statically replacing the weak CRT alloc symbols at link time, and has no dynamic patching like mimalloc. As an alternative, there were several unsuccessfull attempts made by Russell Gallop to use SCUDO in the past, please see thread in https://reviews.llvm.org/D86694. If later someone comes up with a PR of similar performance that uses SCUDO, we could then delete this vendored rpmalloc folder. I've added a new cmake flag `LLVM_ENABLE_RPMALLOC` which essentialy sets `LLVM_INTEGRATED_CRT_ALLOC` to the in-tree rpmalloc source. ### Performance The most obvious test is profling a ThinLTO linking step with LLD. I've used a Clang compilation as a testbed, ie. ``` set OPTS=/GS- /D_ITERATOR_DEBUG_LEVEL=0 -Xclang -O3 -fstrict-aliasing -march=native -flto=thin -fwhole-program-vtables -fuse-ld=lld cmake -G Ninja %ROOT%/llvm -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=TRUE -DLLVM_ENABLE_PROJECTS="clang" -DLLVM_ENABLE_PDB=ON -DLLVM_OPTIMIZED_TABLEGEN=ON -DCMAKE_C_COMPILER=clang-cl.exe -DCMAKE_CXX_COMPILER=clang-cl.exe -DCMAKE_LINKER=lld-link.exe -DLLVM_ENABLE_LLD=ON -DCMAKE_CXX_FLAGS="%OPTS%" -DCMAKE_C_FLAGS="%OPTS%" -DLLVM_ENABLE_LTO=THIN ``` I've profiled the linking step with no LTO cache, with Powershell, such as: ``` Measure-Command { lld-link /nologo @CMakeFiles\clang.rsp /out:bin\clang.exe /implib:lib\clang.lib /pdb:bin\clang.pdb /version:0.0 /machine:x64 /STACK:10000000 /DEBUG /OPT:REF /OPT:ICF /INCREMENTAL:NO /subsystem:console /MANIFEST:EMBED,ID=1 }` ``` Timings: | Machine | Allocator | Time to link | |--------|--------|--------| | 16c/32t AMD Ryzen 9 5950X | Windows Heap | 10 min 38 sec | | | **Rpmalloc** | **4 min 11 sec** | | 32c/64t AMD Ryzen Threadripper PRO 3975WX | Windows Heap | 23 min 29 sec | | | **Rpmalloc** | **2 min 11 sec** | | | **Rpmalloc + /threads:64** | **1 min 50 sec** | | 176 vCPU (2 socket) Intel Xeon Platinium 8481C (fixed clock 2.7 GHz) | Windows Heap | 43 min 40 sec | | | **Rpmalloc** | **1 min 45 sec** | This also improves the overall performance when building with clang-cl. I've profiled a regular compilation of clang itself, ie: ``` set OPTS=/GS- /D_ITERATOR_DEBUG_LEVEL=0 /arch:AVX -fuse-ld=lld cmake -G Ninja %ROOT%/llvm -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=TRUE -DLLVM_ENABLE_PROJECTS="clang;lld" -DLLVM_ENABLE_PDB=ON -DLLVM_OPTIMIZED_TABLEGEN=ON -DCMAKE_C_COMPILER=clang-cl.exe -DCMAKE_CXX_COMPILER=clang-cl.exe -DCMAKE_LINKER=lld-link.exe -DLLVM_ENABLE_LLD=ON -DCMAKE_CXX_FLAGS="%OPTS%" -DCMAKE_C_FLAGS="%OPTS%" ``` This saves approx. 30 sec when building on the Threadripper PRO 3975WX: ``` (default Windows Heap) C:\src\git\llvm-project>hyperfine -r 5 -p "make_llvm.bat stage1_test2" "ninja clang -C stage1_test2" Benchmark 1: ninja clang -C stage1_test2 Time (mean ± σ): 392.716 s ± 3.830 s [User: 17734.025 s, System: 1078.674 s] Range (min … max): 390.127 s … 399.449 s 5 runs (rpmalloc) C:\src\git\llvm-project>hyperfine -r 5 -p "make_llvm.bat stage1_test2" "ninja clang -C stage1_test2" Benchmark 1: ninja clang -C stage1_test2 Time (mean ± σ): 360.824 s ± 1.162 s [User: 15148.637 s, System: 905.175 s] Range (min … max): 359.208 s … 362.288 s 5 runs ```
2024-06-20 10:54:02 -04:00
set(LLVM_ENABLE_RPMALLOC "" CACHE BOOL "Replace the CRT allocator with rpmalloc.")
if(LLVM_ENABLE_RPMALLOC)
if(NOT (CMAKE_SYSTEM_NAME MATCHES "Windows|Linux"))
message(FATAL_ERROR "LLVM_ENABLE_RPMALLOC is only supported on Windows and Linux.")
endif()
if(LLVM_USE_SANITIZER)
message(FATAL_ERROR "LLVM_ENABLE_RPMALLOC cannot be used along with LLVM_USE_SANITIZER!")
endif()
if(WIN32)
if(CMAKE_CONFIGURATION_TYPES)
foreach(BUILD_MODE ${CMAKE_CONFIGURATION_TYPES})
string(TOUPPER "${BUILD_MODE}" uppercase_BUILD_MODE)
if(uppercase_BUILD_MODE STREQUAL "DEBUG")
message(WARNING "The Debug target isn't supported along with LLVM_ENABLE_RPMALLOC!")
endif()
endforeach()
else()
if(CMAKE_BUILD_TYPE AND uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG")
message(FATAL_ERROR "The Debug target isn't supported along with LLVM_ENABLE_RPMALLOC!")
endif()
endif()
endif()
# Override the C runtime allocator with the in-tree rpmalloc
set(LLVM_INTEGRATED_CRT_ALLOC "${CMAKE_CURRENT_SOURCE_DIR}/lib/Support")
set(CMAKE_MSVC_RUNTIME_LIBRARY "MultiThreaded")
endif()
set(LLVM_INTEGRATED_CRT_ALLOC "${LLVM_INTEGRATED_CRT_ALLOC}" CACHE PATH "Replace the Windows CRT allocator with any of {rpmalloc|mimalloc|snmalloc}. Only works with CMAKE_MSVC_RUNTIME_LIBRARY=MultiThreaded.")
[llvm][cmake] Change LLVM_INTEGRATED_CRT_ALLOC to a path instead of a boolean Differential Revision: https://reviews.llvm.org/D87609
2020-09-15 19:18:24 -04:00
if(LLVM_INTEGRATED_CRT_ALLOC)
if(NOT WIN32)
message(FATAL_ERROR "LLVM_INTEGRATED_CRT_ALLOC is only supported on Windows.")
endif()
if(LLVM_USE_SANITIZER)
message(FATAL_ERROR "LLVM_INTEGRATED_CRT_ALLOC cannot be used along with LLVM_USE_SANITIZER!")
endif()
if(CMAKE_BUILD_TYPE AND uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG")
message(FATAL_ERROR "The Debug target isn't supported along with LLVM_INTEGRATED_CRT_ALLOC!")
endif()
endif()
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
# Define options to control the inclusion and default build behavior for
# components which may not strictly be necessary (tools, examples, and tests).
#
# This is primarily to support building smaller or faster project files.
option(LLVM_INCLUDE_TOOLS "Generate build targets for the LLVM tools." ON)
option(LLVM_BUILD_TOOLS
"Build the LLVM tools. If OFF, just generate build targets." ON)
option(LLVM_INCLUDE_UTILS "Generate build targets for the LLVM utils." ON)
[cmake] Create the LLVM_BUILD_UTILS option. This option is the equivalent option to LLVM_BUILD_TOOLS but for executables created via add_llvm_utility. This is a useful tool for improving compile time in situations where LLVM is used as a library and no testing tools are needed. It follows the exact same implemention model as LLVM_BUILD_TOOLS. Since the option is by default set to on, no behavior is changed unless one sets it from the command line to be false. llvm-svn: 275007
2016-07-10 02:43:47 +00:00
option(LLVM_BUILD_UTILS
"Build LLVM utility binaries. If OFF, just generate build targets." ON)
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
[CMake] Provide an option to disable runtimes build This could be used to either disable the runtimes build altogether or avoid building them but still generate the build targets. Differential Revision: https://reviews.llvm.org/D31060 llvm-svn: 298653
2017-03-23 22:40:10 +00:00
option(LLVM_INCLUDE_RUNTIMES "Generate build targets for the LLVM runtimes." ON)
option(LLVM_BUILD_RUNTIMES
"Build the LLVM runtimes. If OFF, just generate build targets." ON)
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
option(LLVM_BUILD_RUNTIME
"Build the LLVM runtime libraries." ON)
option(LLVM_BUILD_EXAMPLES
"Build the LLVM example programs. If OFF, just generate build targets." OFF)
option(LLVM_INCLUDE_EXAMPLES "Generate build targets for the LLVM examples" ON)
option(LLVM_BUILD_TESTS
"Build LLVM unit tests. If OFF, just generate build targets." OFF)
option(LLVM_INCLUDE_TESTS "Generate build targets for the LLVM unit tests." ON)
Add install targets for gtest 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
2023-03-10 17:22:14 -08:00
option(LLVM_INSTALL_GTEST
"Install the llvm gtest library. This should be on if you want to do
stand-alone builds of the other projects and run their unit tests." OFF)
Pull google/benchmark library to the LLVM tree This patch pulls google/benchmark v1.4.1 into the LLVM tree so that any project could use it for benchmark generation. A dummy benchmark is added to `llvm/benchmarks/DummyYAML.cpp` to validate the correctness of the build process. The current version does not utilize LLVM LNT and LLVM CMake infrastructure, but that might be sufficient for most users. Two introduced CMake variables: * `LLVM_INCLUDE_BENCHMARKS` (`ON` by default) generates benchmark targets * `LLVM_BUILD_BENCHMARKS` (`OFF` by default) adds generated benchmark targets to the list of default LLVM targets (i.e. if `ON` benchmarks will be built upon standard build invocation, e.g. `ninja` or `make` with no specific targets) List of modifications: * `BENCHMARK_ENABLE_TESTING` is disabled * `BENCHMARK_ENABLE_EXCEPTIONS` is disabled * `BENCHMARK_ENABLE_INSTALL` is disabled * `BENCHMARK_ENABLE_GTEST_TESTS` is disabled * `BENCHMARK_DOWNLOAD_DEPENDENCIES` is disabled Original discussion can be found here: http://lists.llvm.org/pipermail/llvm-dev/2018-August/125023.html Reviewed by: dberris, lebedev.ri Subscribers: ilya-biryukov, ioeric, EricWF, lebedev.ri, srhines, dschuff, mgorny, krytarowski, fedor.sergeev, mgrang, jfb, llvm-commits Differential Revision: https://reviews.llvm.org/D50894 llvm-svn: 340809
2018-08-28 09:42:41 +00:00
option(LLVM_BUILD_BENCHMARKS "Add LLVM benchmark targets to the list of default
targets. If OFF, benchmarks still could be built using Benchmarks target." OFF)
[benchmark] Re-enable benchmarks on all platforms including Windows The assertion in MCCodeView.cpp was resolved in r340878. This reverts both r340905 and r340836, making benchmarks build by default everywhere. llvm-svn: 341716
2018-09-07 21:47:00 +00:00
option(LLVM_INCLUDE_BENCHMARKS "Generate benchmark targets. If OFF, benchmarks can't be built." ON)
Pull google/benchmark library to the LLVM tree This patch pulls google/benchmark v1.4.1 into the LLVM tree so that any project could use it for benchmark generation. A dummy benchmark is added to `llvm/benchmarks/DummyYAML.cpp` to validate the correctness of the build process. The current version does not utilize LLVM LNT and LLVM CMake infrastructure, but that might be sufficient for most users. Two introduced CMake variables: * `LLVM_INCLUDE_BENCHMARKS` (`ON` by default) generates benchmark targets * `LLVM_BUILD_BENCHMARKS` (`OFF` by default) adds generated benchmark targets to the list of default LLVM targets (i.e. if `ON` benchmarks will be built upon standard build invocation, e.g. `ninja` or `make` with no specific targets) List of modifications: * `BENCHMARK_ENABLE_TESTING` is disabled * `BENCHMARK_ENABLE_EXCEPTIONS` is disabled * `BENCHMARK_ENABLE_INSTALL` is disabled * `BENCHMARK_ENABLE_GTEST_TESTS` is disabled * `BENCHMARK_DOWNLOAD_DEPENDENCIES` is disabled Original discussion can be found here: http://lists.llvm.org/pipermail/llvm-dev/2018-August/125023.html Reviewed by: dberris, lebedev.ri Subscribers: ilya-biryukov, ioeric, EricWF, lebedev.ri, srhines, dschuff, mgorny, krytarowski, fedor.sergeev, mgrang, jfb, llvm-commits Differential Revision: https://reviews.llvm.org/D50894 llvm-svn: 340809
2018-08-28 09:42:41 +00:00
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
option (LLVM_BUILD_DOCS "Build the llvm documentation." OFF)
option (LLVM_INCLUDE_DOCS "Generate build targets for llvm documentation." ON)
option (LLVM_ENABLE_DOXYGEN "Use doxygen to generate llvm API documentation." OFF)
option (LLVM_ENABLE_SPHINX "Use Sphinx to generate llvm documentation." OFF)
[CMake] [OCaml] Add -DLLVM_ENABLE_OCAMLDOC switch Patch by Michael Gorny. llvm-svn: 279544
2016-08-23 18:07:16 +00:00
option (LLVM_ENABLE_OCAMLDOC "Build OCaml bindings documentation." ON)
[cmake] Add a switch to enable/disable bindings. Differential Revision: https://reviews.llvm.org/D42026 llvm-svn: 332816
2018-05-20 08:37:54 +00:00
option (LLVM_ENABLE_BINDINGS "Build bindings." ON)
[llvm][telemetry]Change Telemetry-disabling mechanism. (#128534) Details: - Previously, we used the LLVM_BUILD_TELEMETRY flag to control whether any Telemetry code will be built. This has proven to cause more nuisance to both users of the Telemetry and any further extension of it. (Eg., we needed to put #ifdef around caller/user code) - So the new approach is to: + Remove this flag and introduce LLVM_ENABLE_TELEMETRY which would be true by default. + If LLVM_ENABLE_TELEMETRY is set to FALSE (at buildtime), the library would still be built BUT Telemetry cannot be enabled. And no data can be collected. The benefit of this is that it simplifies user (and extension) code since we just need to put the check on Config::EnableTelemetry. Besides, the Telemetry library itself is very small, hence the additional code to be built would not cause any difference in build performance. --------- Co-authored-by: Pavel Labath <pavel@labath.sk>
2025-02-26 13:01:53 -05:00
option (LLVM_ENABLE_TELEMETRY "Enable the telemetry library. If set to OFF, library cannot be enabled after build (eg., at runtime)" ON)
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
[llvm] Use `GNUInstallDirs` to support custom installation dirs This is the patch for LLVM proper in my series for adding GNUInstallDirs support in all project. Additionally: Create a new `CACHE STRING` variable, `LLVM_EXAMPLES_INSTALL_DIR`, to control where the examples are installed on analogy with the other variables. --- This patch supersedes D28234, which tried to do the same thing but hand-rolled without GNUInstallDirs. This patch nearly reverts commit 3 0fc88bf1dc15a72e2d9809d28019d386b7a7cc0, which was a revert of a prior attempt." (I had to add a space here or else Phabricator detects a reference cycle and won't let me do the form submit.) Reviewed By: compnerd Differential Revision: https://reviews.llvm.org/D100810
2021-12-11 01:36:24 +00:00
set(LLVM_INSTALL_DOXYGEN_HTML_DIR "${CMAKE_INSTALL_DOCDIR}/llvm/doxygen-html"
[cmake] Support overriding remaining HTML doc install directories Support overriding the Doxygen & OCamldoc install directories, and provide a more FHS-compliant defaults for both of them. This extends r282240 that added this override for Sphinx-built documentation. LLVM_INSTALL_DOXYGEN_HTML_DIR and LLVM_INSTALL_OCAMLDOC_HTML_DIR are added, to control the location where Doxygen-generated and OCamldoc-generated HTML docs are installed appropriately. They both specify CMake-style install paths, and therefore can either by relative to the install prefix or absolute. The new defaults are subdirectories of share/doc/llvm, and replace the previous directories of 'docs/html' and 'docs/ocaml/html' that resulted in creating invalid '/usr/docs' that furthermore lacked proper namespacing for the LLVM package. The new defaults are consistent with the ones used for Sphinx HTML documentation, differing only in the last component. Since the 'html' subdirectory is already used for Sphinx docs, the 'doxygen-html' and 'ocaml-html' directories are used instead. Differential Revision: https://reviews.llvm.org/D24935 llvm-svn: 282536
2016-09-27 19:52:29 +00:00
CACHE STRING "Doxygen-generated HTML documentation install directory")
[llvm] Use `GNUInstallDirs` to support custom installation dirs This is the patch for LLVM proper in my series for adding GNUInstallDirs support in all project. Additionally: Create a new `CACHE STRING` variable, `LLVM_EXAMPLES_INSTALL_DIR`, to control where the examples are installed on analogy with the other variables. --- This patch supersedes D28234, which tried to do the same thing but hand-rolled without GNUInstallDirs. This patch nearly reverts commit 3 0fc88bf1dc15a72e2d9809d28019d386b7a7cc0, which was a revert of a prior attempt." (I had to add a space here or else Phabricator detects a reference cycle and won't let me do the form submit.) Reviewed By: compnerd Differential Revision: https://reviews.llvm.org/D100810
2021-12-11 01:36:24 +00:00
set(LLVM_INSTALL_OCAMLDOC_HTML_DIR "${CMAKE_INSTALL_DOCDIR}/llvm/ocaml-html"
[cmake] Support overriding remaining HTML doc install directories Support overriding the Doxygen & OCamldoc install directories, and provide a more FHS-compliant defaults for both of them. This extends r282240 that added this override for Sphinx-built documentation. LLVM_INSTALL_DOXYGEN_HTML_DIR and LLVM_INSTALL_OCAMLDOC_HTML_DIR are added, to control the location where Doxygen-generated and OCamldoc-generated HTML docs are installed appropriately. They both specify CMake-style install paths, and therefore can either by relative to the install prefix or absolute. The new defaults are subdirectories of share/doc/llvm, and replace the previous directories of 'docs/html' and 'docs/ocaml/html' that resulted in creating invalid '/usr/docs' that furthermore lacked proper namespacing for the LLVM package. The new defaults are consistent with the ones used for Sphinx HTML documentation, differing only in the last component. Since the 'html' subdirectory is already used for Sphinx docs, the 'doxygen-html' and 'ocaml-html' directories are used instead. Differential Revision: https://reviews.llvm.org/D24935 llvm-svn: 282536
2016-09-27 19:52:29 +00:00
CACHE STRING "OCamldoc-generated HTML documentation install directory")
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
option (LLVM_BUILD_EXTERNAL_COMPILER_RT
"Build compiler-rt as an external project." OFF)
Allow suppressing host and target info in VersionPrinter Summary: VersionPrinter by default outputs information about the Host CPU and Default target. Printing this information requires linking in a large amount of data, such as supported target triples as C strings, which in turn bloats the binary size. Enable a new CMake option LLVM_VERSION_PRINTER_SHOW_HOST_TARGET_INFO which controls printing of the host and target info. This allows the target triple names to be dead-code stripped. This is a nice win for LLVM clients that wish to minimize their binary size, such as graphics drivers. By default this is ON, so there is no change in the default behavior. Clients who wish to suppress this printing can do so by setting this option to off via CMake. A test app on Linux that uses ParseCommandLineOptions() shows a binary size reduction of 23KB (from 149K to 126K) for a Release build, and 24KB (from 135K to 111K) in a MinSizeRel build. Reviewers: klimek, beanz, bogner, chandlerc, compnerd Reviewed By: compnerd Patch by pammon (Peter Ammon) ! Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D30904 llvm-svn: 300630
2017-04-19 00:03:36 +00:00
option (LLVM_VERSION_PRINTER_SHOW_HOST_TARGET_INFO
"Show target and host info when tools are invoked with --version." ON)
[driver] Make --version show if assertions, etc. are enabled (#87585) It's useful to have some significant build options visible in the version when investigating problems with a specific compiler artifact. This makes it easy to see if assertions, expensive checks, sanitizers, etc. are enabled when checking a compiler version. Example config line output: Build configuration: +unoptimized, +assertions, +asan, +ubsan
2024-04-05 13:01:09 -04:00
option(LLVM_VERSION_PRINTER_SHOW_BUILD_CONFIG
"Show the optional build config flags when tools are invoked with --version." ON)
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
# You can configure which libraries from LLVM you want to include in the
# shared library by setting LLVM_DYLIB_COMPONENTS to a semi-colon delimited
# list of LLVM components. All component names handled by llvm-config are valid.
if(NOT DEFINED LLVM_DYLIB_COMPONENTS)
set(LLVM_DYLIB_COMPONENTS "all" CACHE STRING
"Semicolon-separated list of components to include in libLLVM, or \"all\".")
endif()
[cmake] Remove LLVM_{BUILD,LINK}_LLVM_DYLIB options on Windows Summary: The options aren't supported so they can be removed. Reviewers: beanz, smeenai, compnerd Reviewed By: compnerd Subscribers: mgorny, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69877
2019-11-08 10:05:37 -08:00
[RFC] Build LLVM-C.dll on MSVC that exports only the C API Summary: Hello! This commit adds a LLVM-C target that is always built on MSVC. A big fat warning, this is my first cmake code ever so there is a fair bit of I-have-no-idea-what-I'm-doing going on here. Which is also why I placed it outside of llvm-shlib as I was afraid of breaking things of other people. Secondly llvm-shlib builds a LLVM.so which exports all symbols and then does a thin library that points to it, but on Windows we do not build a LLVM.dll so that would have complicated the code more. The patch includes a python script that calls dumpbin.exe to get all of the symbols from the built libraries. It then grabs all the symbols starting with LLVM and generates the export file from those. The export file is then used to create the library just like the LLVM-C that is built on darwin. Improvements that I need help with, to follow up this review. - Get cmake to make sure that dumpbin.exe is on the path and wire the full path to the script. - Use LLVM-C.dll when building llvm-c-test so we can verify that the symbols are exported. - Bundle the LLVM-C.dll with the windows installer. Why do this? I'm building a language frontend which is self-hosting, and on windows because of various tooling issues we have a problem of consuming the LLVM*.lib directly on windows. Me and the users of my projects using LLVM would be greatly helped by having LLVM-C.dll built and shipped by the Windows installer. Not only does LLVM takes forever to build, you have to run a extra python script in order to get the final DLL. Any comments, thoughts or help is greatly appreciated. Cheers, Jakob. Patch by: Wallbraker (Jakob Bornecrantz) Reviewers: compnerd, beanz, hans, smeenai Reviewed By: beanz Subscribers: xbolva00, bhelyer, Memnarch, rnk, fedor.sergeev, chapuni, smeenai, john.brawn, deadalnix, llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D35077 llvm-svn: 339151
2018-08-07 15:54:50 +00:00
if(MSVC)
Use response file when generating LLVM-C.dll As discovered in D56774 the command line gets to long, so use a response file to give the script the libs. This change has been tested and is confirmed working for me. Commited on behalf of Jakob Bornecrantz. Differential Revision: https://reviews.llvm.org/D56781 llvm-svn: 356443
2019-03-19 09:14:09 +00:00
option(LLVM_BUILD_LLVM_C_DYLIB "Build LLVM-C.dll (Windows only)" ON)
[cmake] Emit an error for -DBUILD_SHARED_LIBS=ON on Windows Summary: The BUILD_SHARED_LIBS=ON build fails on Windows, so prevent users from enabling it. Reviewers: beanz, smeenai, compnerd, phosek Reviewed By: beanz Subscribers: mgorny, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70161
2019-11-14 09:18:44 -08:00
if (BUILD_SHARED_LIBS)
message(FATAL_ERROR "BUILD_SHARED_LIBS options is not supported on Windows.")
endif()
[NFC] Remove whitespaces in `llvm/CMakeLists.txt`
2024-11-16 23:51:57 +08:00
else()
[RFC] Build LLVM-C.dll on MSVC that exports only the C API Summary: Hello! This commit adds a LLVM-C target that is always built on MSVC. A big fat warning, this is my first cmake code ever so there is a fair bit of I-have-no-idea-what-I'm-doing going on here. Which is also why I placed it outside of llvm-shlib as I was afraid of breaking things of other people. Secondly llvm-shlib builds a LLVM.so which exports all symbols and then does a thin library that points to it, but on Windows we do not build a LLVM.dll so that would have complicated the code more. The patch includes a python script that calls dumpbin.exe to get all of the symbols from the built libraries. It then grabs all the symbols starting with LLVM and generates the export file from those. The export file is then used to create the library just like the LLVM-C that is built on darwin. Improvements that I need help with, to follow up this review. - Get cmake to make sure that dumpbin.exe is on the path and wire the full path to the script. - Use LLVM-C.dll when building llvm-c-test so we can verify that the symbols are exported. - Bundle the LLVM-C.dll with the windows installer. Why do this? I'm building a language frontend which is self-hosting, and on windows because of various tooling issues we have a problem of consuming the LLVM*.lib directly on windows. Me and the users of my projects using LLVM would be greatly helped by having LLVM-C.dll built and shipped by the Windows installer. Not only does LLVM takes forever to build, you have to run a extra python script in order to get the final DLL. Any comments, thoughts or help is greatly appreciated. Cheers, Jakob. Patch by: Wallbraker (Jakob Bornecrantz) Reviewers: compnerd, beanz, hans, smeenai Reviewed By: beanz Subscribers: xbolva00, bhelyer, Memnarch, rnk, fedor.sergeev, chapuni, smeenai, john.brawn, deadalnix, llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D35077 llvm-svn: 339151
2018-08-07 15:54:50 +00:00
option(LLVM_BUILD_LLVM_C_DYLIB "Build libllvm-c re-export library (Darwin only)" OFF)
Initial changes for llvm shared library build using explicit visibility annotations These are my initial build and code changes to supporting building llvm as shared library/DLL on windows(without force exporting all symbols) and making symbol visibility hidden by default on Linux which adding explicit symbol visibility macros to the whole llvm codebase. Updated cmake code to allow building llvm-shlib on windows by appending /WHOLEARCHIVE:lib to the linker options. Remove the hardcoded CMake error from using LLVM_BUILD_LLVM_DYLIB on windows. Updated CMake to define new macros to control conditional export macros in llvm/Support/Compiler.h Use /Zc:dllexportInlines- when compiling with clang-cl on windows with a opt out CMake option to disable using it. Replace some use of LLVM_EXTERNAL_VISIBILITY with new export macros. Some of the cmake and code changes are based on @tstellar's earlier PR https://github.com/llvm/llvm-project/pull/67502. I have Windows building using clang-cl, while for MSVC its at-least able to build libllvm, but some tests can't build because llvm iterator template metaprogramming that doesn't work well with dllexport. Linux should build without issue. My full branch is here https://github.com/fsfod/llvm-project/tree/llvm-export-api-20.0 and including all the auto generated export macros from clang tooling based system.
2024-09-06 18:51:44 +01:00
endif()
# Used to test building the llvm shared library with explicit symbol visibility on
# Windows and Linux. For ELF platforms default symbols visibility is set to hidden.
set(LLVM_BUILD_LLVM_DYLIB_VIS FALSE CACHE BOOL "")
mark_as_advanced(LLVM_BUILD_LLVM_DYLIB_VIS)
set(CAN_BUILD_LLVM_DYLIB OFF)
if(NOT MSVC OR LLVM_BUILD_LLVM_DYLIB_VIS)
set(CAN_BUILD_LLVM_DYLIB ON)
endif()
cmake_dependent_option(LLVM_LINK_LLVM_DYLIB "Link tools against the libllvm dynamic library" OFF
"CAN_BUILD_LLVM_DYLIB" OFF)
set(LLVM_BUILD_LLVM_DYLIB_default OFF)
if(LLVM_LINK_LLVM_DYLIB OR LLVM_BUILD_LLVM_C_DYLIB)
set(LLVM_BUILD_LLVM_DYLIB_default ON)
endif()
cmake_dependent_option(LLVM_BUILD_LLVM_DYLIB "Build libllvm dynamic library" ${LLVM_BUILD_LLVM_DYLIB_default}
"CAN_BUILD_LLVM_DYLIB" OFF)
cmake_dependent_option(LLVM_DYLIB_EXPORT_INLINES "Force inline members of classes to be DLL exported when
building with clang-cl so the libllvm DLL is compatible with MSVC"
OFF
"MSVC;LLVM_BUILD_LLVM_DYLIB_VIS" OFF)
if(LLVM_BUILD_LLVM_DYLIB_VIS)
set(LLVM_BUILD_LLVM_DYLIB ON)
[RFC] Build LLVM-C.dll on MSVC that exports only the C API Summary: Hello! This commit adds a LLVM-C target that is always built on MSVC. A big fat warning, this is my first cmake code ever so there is a fair bit of I-have-no-idea-what-I'm-doing going on here. Which is also why I placed it outside of llvm-shlib as I was afraid of breaking things of other people. Secondly llvm-shlib builds a LLVM.so which exports all symbols and then does a thin library that points to it, but on Windows we do not build a LLVM.dll so that would have complicated the code more. The patch includes a python script that calls dumpbin.exe to get all of the symbols from the built libraries. It then grabs all the symbols starting with LLVM and generates the export file from those. The export file is then used to create the library just like the LLVM-C that is built on darwin. Improvements that I need help with, to follow up this review. - Get cmake to make sure that dumpbin.exe is on the path and wire the full path to the script. - Use LLVM-C.dll when building llvm-c-test so we can verify that the symbols are exported. - Bundle the LLVM-C.dll with the windows installer. Why do this? I'm building a language frontend which is self-hosting, and on windows because of various tooling issues we have a problem of consuming the LLVM*.lib directly on windows. Me and the users of my projects using LLVM would be greatly helped by having LLVM-C.dll built and shipped by the Windows installer. Not only does LLVM takes forever to build, you have to run a extra python script in order to get the final DLL. Any comments, thoughts or help is greatly appreciated. Cheers, Jakob. Patch by: Wallbraker (Jakob Bornecrantz) Reviewers: compnerd, beanz, hans, smeenai Reviewed By: beanz Subscribers: xbolva00, bhelyer, Memnarch, rnk, fedor.sergeev, chapuni, smeenai, john.brawn, deadalnix, llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D35077 llvm-svn: 339151
2018-08-07 15:54:50 +00:00
endif()
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
[cmake] Prevent building with BUILD_SHARED_LIBS and LLVM_LINK_LLVM_DYLIB Summary: This doesn't work, so error early if someone tries it. Reviewers: beanz, smeenai, compnerd, phosek Reviewed By: beanz Subscribers: mgorny, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70160
2019-11-13 20:29:19 -08:00
if (LLVM_LINK_LLVM_DYLIB AND BUILD_SHARED_LIBS)
message(FATAL_ERROR "Cannot enable BUILD_SHARED_LIBS with LLVM_LINK_LLVM_DYLIB. We recommend disabling BUILD_SHARED_LIBS.")
endif()
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
option(LLVM_OPTIMIZED_TABLEGEN "Force TableGen to be built with optimization" OFF)
[CMAKE] fix LLVM_OPTIMIZED_TABLEGEN for Visual Studio At the moment optimized tablegen is generated by LLVM_USE_HOST_TOOLS variable that is not set for Visual Sudio since LLVM_ENABLE_ASSERTIONS depends on CMAKE_BUILD_TYPE value that is not equal to "DEBUG" in case of Visual Studio soltion generation. Modified to do not depend on LLVM_ENABLE_ASSERTIONS value in VS and Xcode cases Reviewers: beanz Subscribers: RKSimon, llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D27135 llvm-svn: 288042
2016-11-28 17:12:09 +00:00
if(CMAKE_CROSSCOMPILING OR (LLVM_OPTIMIZED_TABLEGEN AND (LLVM_ENABLE_ASSERTIONS OR CMAKE_CONFIGURATION_TYPES)))
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
set(LLVM_USE_HOST_TOOLS ON)
endif()
[CMake] Add new cmake option to control adding comments in GenDAGISel Add new cmake option `LLVM_OMIT_DAGISEL_COMMENTS` to control adding of comments in GenDAGISel for none debug builds Ref: https://reviews.llvm.org/D78884 Reviewed By: nemanjai, MaskRay, #powerpc Differential Revision: https://reviews.llvm.org/D114122
2021-11-17 15:43:35 -06:00
option(LLVM_OMIT_DAGISEL_COMMENTS "Do not add comments to DAG ISel" ON)
if (CMAKE_BUILD_TYPE AND uppercase_CMAKE_BUILD_TYPE MATCHES "^(RELWITHDEBINFO|DEBUG)$")
set(LLVM_OMIT_DAGISEL_COMMENTS OFF)
endif()
Remove cmake checks for MSVC 1900 / VS 2013 Our minimum Visual C++ version is 19.10 from Visual Studio 2017. llvm-svn: 367362
2019-07-30 22:49:11 +00:00
if (MSVC_IDE)
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
option(LLVM_ADD_NATIVE_VISUALIZERS_TO_SOLUTION "Configure project to use Visual Studio native visualizers" TRUE)
endif()
[LIT] Added an option to llvm-lit to emit the necessary test coverage data, 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
2023-07-26 16:46:09 +05:30
if(NOT LLVM_INDIVIDUAL_TEST_COVERAGE)
if(LLVM_BUILD_INSTRUMENTED OR LLVM_BUILD_INSTRUMENTED_COVERAGE OR LLVM_ENABLE_IR_PGO)
if(NOT LLVM_PROFILE_MERGE_POOL_SIZE)
# A pool size of 1-2 is probably sufficient on an SSD. 3-4 should be fine
# for spinning disks. Anything higher may only help on slower mediums.
set(LLVM_PROFILE_MERGE_POOL_SIZE "4")
[LIT] Added an option to llvm-lit to emit the necessary test coverage data, 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
2023-07-21 14:56:02 +05:30
endif()
[LIT] Added an option to llvm-lit to emit the necessary test coverage data, 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
2023-07-26 16:46:09 +05:30
if(NOT LLVM_PROFILE_FILE_PATTERN)
if(NOT LLVM_PROFILE_DATA_DIR)
file(TO_NATIVE_PATH "${LLVM_BINARY_DIR}/profiles" LLVM_PROFILE_DATA_DIR)
endif()
file(TO_NATIVE_PATH "${LLVM_PROFILE_DATA_DIR}/%${LLVM_PROFILE_MERGE_POOL_SIZE}m.profraw" LLVM_PROFILE_FILE_PATTERN)
endif()
if(NOT LLVM_CSPROFILE_FILE_PATTERN)
if(NOT LLVM_CSPROFILE_DATA_DIR)
file(TO_NATIVE_PATH "${LLVM_BINARY_DIR}/csprofiles" LLVM_CSPROFILE_DATA_DIR)
endif()
file(TO_NATIVE_PATH "${LLVM_CSPROFILE_DATA_DIR}/%${LLVM_PROFILE_MERGE_POOL_SIZE}m.profraw" LLVM_CSPROFILE_FILE_PATTERN)
[PGO] Context sensitive PGO (part 4) Part 4 of CSPGO changes: (1) add support in cmake for cspgo build. (2) fix an issue in big endian. (3) test cases. Differential Revision: https://reviews.llvm.org/D54175 llvm-svn: 355541
2019-03-06 19:31:37 +00:00
endif()
endif()
Add support for collating profiles for use with code coverage Differential Revision: http://reviews.llvm.org/D20993 llvm-svn: 272599
2016-06-13 23:33:48 +00:00
endif()
[cmake] Move LLVM_BUILD_STATIC check to an earlier point Summary: The motivation for this is to enable correct detection of dlopen() on Android. Android does not provide a static version of libdl, so if we add the -static flag after performing the check, it will succeed even though subsequent link steps will fail. With this change we correctly detect the absence of libdl in a LLVM_BUILD_STATIC build on Android. The link itself still does not succeed because the code does not check the result of this check properly, but I plan to fix that in a separate change. Reviewers: beanz Subscribers: danalbert, mgorny, srhines, tberghammer, llvm-commits Differential Revision: https://reviews.llvm.org/D26463 llvm-svn: 287220
2016-11-17 11:22:23 +00:00
if (LLVM_BUILD_STATIC)
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -static")
[CMake] Use find_library for ncurses 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
2020-08-31 15:11:39 -07:00
# Remove shared library suffixes from use in find_library
foreach (shared_lib_suffix ${CMAKE_SHARED_LIBRARY_SUFFIX} ${CMAKE_IMPORT_LIBRARY_SUFFIX})
list(FIND CMAKE_FIND_LIBRARY_SUFFIXES ${shared_lib_suffix} shared_lib_suffix_idx)
if(NOT ${shared_lib_suffix_idx} EQUAL -1)
list(REMOVE_AT CMAKE_FIND_LIBRARY_SUFFIXES ${shared_lib_suffix_idx})
endif()
endforeach()
[cmake] Move LLVM_BUILD_STATIC check to an earlier point Summary: The motivation for this is to enable correct detection of dlopen() on Android. Android does not provide a static version of libdl, so if we add the -static flag after performing the check, it will succeed even though subsequent link steps will fail. With this change we correctly detect the absence of libdl in a LLVM_BUILD_STATIC build on Android. The link itself still does not succeed because the code does not check the result of this check properly, but I plan to fix that in a separate change. Reviewers: beanz Subscribers: danalbert, mgorny, srhines, tberghammer, llvm-commits Differential Revision: https://reviews.llvm.org/D26463 llvm-svn: 287220
2016-11-17 11:22:23 +00:00
endif()
[CMake] Use libtool for runtimes when building for Apple platform LLVM CMake build already uses libtool instead of ar when building for Apple platform and we should be using the same when building runtimes. To do so, this change extracts the logic for finding libtool into a separate file and then uses it from both the LLVM build as well as the LLVM runtimes build. Differential Revision: https://reviews.llvm.org/D62769 llvm-svn: 362313
2019-06-02 02:05:01 +00:00
# Use libtool instead of ar if you are both on an Apple host, and targeting Apple.
if(CMAKE_HOST_APPLE AND APPLE)
include(UseLibtool)
endif()
[CMake] Introduce LLVM_TARGET_TRIPLE_ENV as an option to override LLVM_DEFAULT_TARGET_TRIPLE at runtime. No behavior is changed if LLVM_TARGET_TRIPLE_ENV is blank or undefined. If LLVM_TARGET_TRIPLE_ENV is "TEST_TARGET_TRIPLE" and $TEST_TARGET_TRIPLE is not blank, llvm::sys::getDefaultTargetTriple() returns $TEST_TARGET_TRIPLE. Lit resets config.target_triple and config.environment[LLVM_TARGET_TRIPLE_ENV] to change the default target. Without changing LLVM_DEFAULT_TARGET_TRIPLE nor rebuilding, lit can be run; TEST_TARGET_TRIPLE=i686-pc-win32 bin/llvm-lit -sv path/to/test/ TEST_TARGET_TRIPLE=i686-pc-win32 ninja check-clang-tools Differential Revision: https://reviews.llvm.org/D33662 llvm-svn: 305632
2017-06-17 03:19:08 +00:00
# Override the default target with an environment variable named by LLVM_TARGET_TRIPLE_ENV.
set(LLVM_TARGET_TRIPLE_ENV CACHE STRING "The name of environment variable to override default target. Disabled by blank.")
mark_as_advanced(LLVM_TARGET_TRIPLE_ENV)
[runtimes] Set LLVM_ENABLE_PER_TARGET_RUNTIME_DIR_default to ON for OS390 Reviewed By: abhina.sreeskantharajan, zibi Differential Revision: https://reviews.llvm.org/D143916
2023-02-13 10:31:49 -05:00
if(CMAKE_SYSTEM_NAME MATCHES "BSD|Linux|OS390")
Revert "Revert "[CMake] Enable LLVM_ENABLE_PER_TARGET_RUNTIME_DIR by default on Linux"" This reverts commit 90c9d41c8acc34fb68958f373eb23f53c1b1c840. Keeping arm* LLVM_ENABLE_PER_TARGET_RUNTIME_DIR=on is sufficient to work around LLVM_ENABLE_RUNTIMES not working well with arm. It is more important for LLVM_ENABLE_PROJECTS and LLVM_ENABLE_RUNTIMES to match in the file hierarchy.
2022-06-21 13:13:31 -07:00
set(LLVM_ENABLE_PER_TARGET_RUNTIME_DIR_default ON)
else()
set(LLVM_ENABLE_PER_TARGET_RUNTIME_DIR_default OFF)
endif()
set(LLVM_ENABLE_PER_TARGET_RUNTIME_DIR ${LLVM_ENABLE_PER_TARGET_RUNTIME_DIR_default} CACHE BOOL
Support for multiarch runtimes layout This change adds a support for multiarch style runtimes layout, so in addition to the existing layout where runtimes get installed to: lib/clang/$version/lib/$os Clang now allows runtimes to be installed to: lib/clang/$version/$target/lib This also includes libc++, libc++abi and libunwind; today those are assumed to be in Clang library directory built for host, with the new layout it is possible to install libc++, libc++abi and libunwind into the runtime directory built for different targets. The use of new layout is enabled by setting the LLVM_ENABLE_RUNTIME_TARGET_DIR CMake variable and is supported by both projects and runtimes layouts. The runtimes CMake build has been further modified to use the new layout when building runtimes for multiple targets. Differential Revision: https://reviews.llvm.org/D45604 llvm-svn: 335809
2018-06-28 03:11:52 +00:00
"Enable per-target runtimes directory")
[cmake] Changes to get Windows self-host working with PGO Fixes quoting of profile arguments to work on Windows Suppresses adding profile arguments to linker flags when using lld-link Avoids -fprofile-instr-use being added to rc.exe flags Removes duplicated adding of -fprofile-instr-use to linker flags (since r355541) Move handling LLVM_PROFDATA_FILE to HandleLLVMOptions.cmake Differential Revision: https://reviews.llvm.org/D62063 llvm-svn: 372209
2019-09-18 09:43:13 +00:00
set(LLVM_PROFDATA_FILE "" CACHE FILEPATH
"Profiling data file to use when compiling in order to improve runtime performance.")
[CMake] Find python before searching for python modules In the top-level llvm `CMakeLists.txt`, we need to call `find_package(Python3)` *before* including `config-ix.cmake`, otherwise the latter will not be able to successfully search for python modules using `find_python_module()`. Also set `LLVM_MINIMUM_PYTHON_VERSION` before calling `find_package(Python3)`, moving it to `CMakeLists.txt` from `HandleLLVMOptions.cmake`. Reviewed By: compnerd Differential Revision: https://reviews.llvm.org/D131191
2022-08-04 21:04:35 +02:00
if(LLVM_INCLUDE_TESTS)
Reland "[python] Bump Python minimum version to 3.8 (#78828)" This reverts commit b6824c9d459da059e247a60c1ebd1aeb580dacc2. This relands commit 0a6c74e21cc6750c843310ab35b47763cddaaf32. The original commit was reverted due to buildbot failures. These bots should be updated now, so hopefully this will stick.
2024-06-07 23:18:28 +00:00
# All LLVM Python files should be compatible down to this minimum version.
set(LLVM_MINIMUM_PYTHON_VERSION 3.8)
[CMake] Find python before searching for python modules In the top-level llvm `CMakeLists.txt`, we need to call `find_package(Python3)` *before* including `config-ix.cmake`, otherwise the latter will not be able to successfully search for python modules using `find_python_module()`. Also set `LLVM_MINIMUM_PYTHON_VERSION` before calling `find_package(Python3)`, moving it to `CMakeLists.txt` from `HandleLLVMOptions.cmake`. Reviewed By: compnerd Differential Revision: https://reviews.llvm.org/D131191
2022-08-04 21:04:35 +02:00
else()
# FIXME: it is unknown if this is the actual minimum bound
set(LLVM_MINIMUM_PYTHON_VERSION 3.0)
endif()
# Find python before including config-ix, since it needs to be able to search
# for python modules.
find_package(Python3 ${LLVM_MINIMUM_PYTHON_VERSION} REQUIRED
COMPONENTS Interpreter)
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
# All options referred to from HandleLLVMOptions have to be specified
# BEFORE this include, otherwise options will not be correctly set on
# first cmake run
include(config-ix)
# By default, we target the host, but this can be overridden at CMake
[LLVM][AIX] Prefer a 32-bit default target triple on AIX If the user doesn't specify a default target triple, the LLVM CMake usually defaults us into the host triple. This is a problem when building Clang/LLVM on 64-bit AIX (i.e. powerpc64-ibm-aix), as the host toolchain (e.g. ar, ld, nm, dump) all expect the compiler to generate 32-bit objects by default (which both GCC and XL on the platform do) and will hard error if passed a 64-bit object without an explicit option or environment setting. This breaks downstream consumers, such as builds generated with build tools like CMake, which when they invoke clang, etc. without explicit bitmode flags also expect 32-bit mode. This patch changes the default target selection when the host is powerpc64-ibm-aix to prefer powerpc-ibm-aix to avoid these issues. We don't update the runtimes/CMakeList.txt since the default is less meaningful as we assume runtimes will need to build for both targets anyways. Differential Revision: https://reviews.llvm.org/D118377
2022-01-27 10:09:27 -06:00
# invocation time. Except on 64-bit AIX, where the system toolchain
# expect 32-bit objects by default.
if("${LLVM_HOST_TRIPLE}" MATCHES "^powerpc64-ibm-aix")
[CMake] Remove SetTargetTriple (#66464) This module is only used in two places and its logic can be inlined and simplified.
2023-09-14 23:44:13 -07:00
string(REGEX REPLACE "^powerpc64" "powerpc" LLVM_DEFAULT_TARGET_TRIPLE_DEFAULT "${LLVM_HOST_TRIPLE}")
[LLVM][AIX] Prefer a 32-bit default target triple on AIX If the user doesn't specify a default target triple, the LLVM CMake usually defaults us into the host triple. This is a problem when building Clang/LLVM on 64-bit AIX (i.e. powerpc64-ibm-aix), as the host toolchain (e.g. ar, ld, nm, dump) all expect the compiler to generate 32-bit objects by default (which both GCC and XL on the platform do) and will hard error if passed a 64-bit object without an explicit option or environment setting. This breaks downstream consumers, such as builds generated with build tools like CMake, which when they invoke clang, etc. without explicit bitmode flags also expect 32-bit mode. This patch changes the default target selection when the host is powerpc64-ibm-aix to prefer powerpc-ibm-aix to avoid these issues. We don't update the runtimes/CMakeList.txt since the default is less meaningful as we assume runtimes will need to build for both targets anyways. Differential Revision: https://reviews.llvm.org/D118377
2022-01-27 10:09:27 -06:00
else()
[CMake] Only set LLVM_DEFAULT_TARGET_TRIPLE to LLVM_HOST_TRIPLE when native target is enabled This is for case when native target like X86 is not in LLVM_TARGETS_TO_BUILD. Right now LLVM_DEFAULT_TARGET_TRIPLE is set to LLVM_HOST_TRIPLE even when native target is not enabled, As a result, many lit tests will fail because default_triple is set for lit test but not enabled when build LLVM. Reviewed By: smeenai Differential Revision: https://reviews.llvm.org/D134972
2022-11-04 12:37:07 -07:00
# Only set default triple when native target is enabled.
if (LLVM_NATIVE_TARGET)
[CMake] Remove SetTargetTriple (#66464) This module is only used in two places and its logic can be inlined and simplified.
2023-09-14 23:44:13 -07:00
set(LLVM_DEFAULT_TARGET_TRIPLE_DEFAULT "${LLVM_HOST_TRIPLE}")
[CMake] Only set LLVM_DEFAULT_TARGET_TRIPLE to LLVM_HOST_TRIPLE when native target is enabled This is for case when native target like X86 is not in LLVM_TARGETS_TO_BUILD. Right now LLVM_DEFAULT_TARGET_TRIPLE is set to LLVM_HOST_TRIPLE even when native target is not enabled, As a result, many lit tests will fail because default_triple is set for lit test but not enabled when build LLVM. Reviewed By: smeenai Differential Revision: https://reviews.llvm.org/D134972
2022-11-04 12:37:07 -07:00
endif()
[LLVM][AIX] Prefer a 32-bit default target triple on AIX If the user doesn't specify a default target triple, the LLVM CMake usually defaults us into the host triple. This is a problem when building Clang/LLVM on 64-bit AIX (i.e. powerpc64-ibm-aix), as the host toolchain (e.g. ar, ld, nm, dump) all expect the compiler to generate 32-bit objects by default (which both GCC and XL on the platform do) and will hard error if passed a 64-bit object without an explicit option or environment setting. This breaks downstream consumers, such as builds generated with build tools like CMake, which when they invoke clang, etc. without explicit bitmode flags also expect 32-bit mode. This patch changes the default target selection when the host is powerpc64-ibm-aix to prefer powerpc-ibm-aix to avoid these issues. We don't update the runtimes/CMakeList.txt since the default is less meaningful as we assume runtimes will need to build for both targets anyways. Differential Revision: https://reviews.llvm.org/D118377
2022-01-27 10:09:27 -06:00
endif()
[CMake] Remove SetTargetTriple (#66464) This module is only used in two places and its logic can be inlined and simplified.
2023-09-14 23:44:13 -07:00
set(LLVM_DEFAULT_TARGET_TRIPLE "${LLVM_DEFAULT_TARGET_TRIPLE_DEFAULT}" CACHE STRING
"Default target for which LLVM will generate code." )
message(STATUS "LLVM default target triple: ${LLVM_DEFAULT_TARGET_TRIPLE}")
set(LLVM_TARGET_TRIPLE "${LLVM_DEFAULT_TARGET_TRIPLE}")
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
[test] Fix plugin tests Recommit of r361790 that was temporarily reverted in r361793 due to bot breakage. Summary: The following changes were required to fix these tests: 1) Change LLVM_ENABLE_PLUGINS to an option and move it to llvm/CMakeLists.txt with an appropriate default -- which matches the original default behavior. 2) Move the plugins directory from clang/test/Analysis clang/lib/Analysis. It's not enough to add an exclude to the lit.local.cfg file because add_lit_testsuites recurses the tree and automatically adds the appropriate `check-` targets, which don't make sense for the plugins because they aren't tests and don't have `RUN` statements. Here's a list of the `clang-check-anlysis*` targets with this change: ``` $ ninja -t targets all| sed -n "s/.*\/\(check[^:]*\):.*/\1/p" | sort -u | grep clang-analysis check-clang-analysis check-clang-analysis-checkers check-clang-analysis-copypaste check-clang-analysis-diagnostics check-clang-analysis-engine check-clang-analysis-exploration_order check-clang-analysis-html_diagnostics check-clang-analysis-html_diagnostics-relevant_lines check-clang-analysis-inlining check-clang-analysis-objc check-clang-analysis-unified-sources check-clang-analysis-z3 ``` 3) Simplify the logic and only include the subdirectories under clang/lib/Analysis/plugins if LLVM_ENABLE_PLUGINS is set. Reviewed By: NoQ Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D62445 llvm-svn: 362328
2019-06-02 15:53:43 +00:00
if(WIN32 OR CYGWIN)
if(BUILD_SHARED_LIBS OR LLVM_BUILD_LLVM_DYLIB)
set(LLVM_ENABLE_PLUGINS_default ON)
else()
set(LLVM_ENABLE_PLUGINS_default OFF)
endif()
else()
Unbreak my hasty "unbreak" cmake fix llvm-svn: 362492
2019-06-04 11:33:49 +00:00
set(LLVM_ENABLE_PLUGINS_default ${LLVM_ENABLE_PIC})
[test] Fix plugin tests Recommit of r361790 that was temporarily reverted in r361793 due to bot breakage. Summary: The following changes were required to fix these tests: 1) Change LLVM_ENABLE_PLUGINS to an option and move it to llvm/CMakeLists.txt with an appropriate default -- which matches the original default behavior. 2) Move the plugins directory from clang/test/Analysis clang/lib/Analysis. It's not enough to add an exclude to the lit.local.cfg file because add_lit_testsuites recurses the tree and automatically adds the appropriate `check-` targets, which don't make sense for the plugins because they aren't tests and don't have `RUN` statements. Here's a list of the `clang-check-anlysis*` targets with this change: ``` $ ninja -t targets all| sed -n "s/.*\/\(check[^:]*\):.*/\1/p" | sort -u | grep clang-analysis check-clang-analysis check-clang-analysis-checkers check-clang-analysis-copypaste check-clang-analysis-diagnostics check-clang-analysis-engine check-clang-analysis-exploration_order check-clang-analysis-html_diagnostics check-clang-analysis-html_diagnostics-relevant_lines check-clang-analysis-inlining check-clang-analysis-objc check-clang-analysis-unified-sources check-clang-analysis-z3 ``` 3) Simplify the logic and only include the subdirectories under clang/lib/Analysis/plugins if LLVM_ENABLE_PLUGINS is set. Reviewed By: NoQ Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D62445 llvm-svn: 362328
2019-06-02 15:53:43 +00:00
endif()
option(LLVM_ENABLE_PLUGINS "Enable plugin support" ${LLVM_ENABLE_PLUGINS_default})
[CMake] Change -DENABLE_EXPERIMENTAL_NEW_PASS_MANAGER=off to -DLLVM_ENABLE_NEW_PASS_MANAGER=off 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
2021-08-26 14:25:31 -07:00
set(LLVM_ENABLE_NEW_PASS_MANAGER TRUE CACHE BOOL
Turn on the new pass manager by default 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
2021-01-25 11:00:56 -08:00
"Enable the new pass manager by default.")
[CMake] Change -DENABLE_EXPERIMENTAL_NEW_PASS_MANAGER=off to -DLLVM_ENABLE_NEW_PASS_MANAGER=off 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
2021-08-26 14:25:31 -07:00
if(NOT LLVM_ENABLE_NEW_PASS_MANAGER)
[cmake] Remove LLVM_ENABLE_NEW_PASS_MANAGER cmake option Or rather, error out if it is set to something other than ON. This removes the ability to enable the legacy pass manager by default, but does not remove the ability to explicitly enable it through various flags like -flegacy-pass-manager or -enable-new-pm=0. I checked, and our test suite definitely doesn't pass with LLVM_ENABLE_NEW_PASS_MANAGER=OFF anymore. Differential Revision: https://reviews.llvm.org/D123126
2022-04-05 15:05:46 +02:00
message(FATAL_ERROR "Enabling the legacy pass manager on the cmake level is"
" no longer supported.")
[CMake] Change -DENABLE_EXPERIMENTAL_NEW_PASS_MANAGER=off to -DLLVM_ENABLE_NEW_PASS_MANAGER=off 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
2021-08-26 14:25:31 -07:00
endif()
Reland [CMake][NewPM] Move ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER into llvm/ 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
2020-11-24 20:40:47 -08:00
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
include(HandleLLVMOptions)
######
# Configure all of the various header file fragments LLVM uses which depend on
# configuration variables.
set(LLVM_ENUM_TARGETS "")
set(LLVM_ENUM_ASM_PRINTERS "")
set(LLVM_ENUM_ASM_PARSERS "")
set(LLVM_ENUM_DISASSEMBLERS "")
[MCA] Moving the target specific CustomBehaviour impl. from /tools/llvm-mca/ to /lib/Target/. Differential Revision: https://reviews.llvm.org/D106775
2021-07-24 20:27:41 -07:00
set(LLVM_ENUM_TARGETMCAS "")
[llvm-exegesis] Initialize all supported targets Enable registration of multiple exegesis targets at once. Use idiomatic approach to defining target select macros, but leave code in the llvm-mca sub-directories for now. This is a stepping stone towards allowing llvm-exegesis benchmarking via simulator or testing in non-target dependent tests. Differential Revision: https://reviews.llvm.org/D133605
2022-09-22 09:02:22 -07:00
set(LLVM_ENUM_EXEGESIS "")
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
foreach(t ${LLVM_TARGETS_TO_BUILD})
set( td ${LLVM_MAIN_SRC_DIR}/lib/Target/${t} )
[llvm][CMake] Improve error message for unknown or experimental targets 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
2023-08-14 08:39:10 +00:00
# Make sure that any experimental targets were passed via
[cmake] Update experimental target error message Summary: Update this error message indicate this test only ensures experimental targets were passed via LLVM_EXPERIMENTAL_TARGETS_TO_BUILD. Originally, this test validated all targets, but in r184923, it was moved after the LLVMBUILDTOOL test, which also validates all targets, making that part of the test redundant. Differential Revision: https://reviews.llvm.org/D41273 llvm-svn: 321012
2017-12-18 19:15:15 +00:00
# LLVM_EXPERIMENTAL_TARGETS_TO_BUILD, not LLVM_TARGETS_TO_BUILD.
[llvm][CMake] Improve error message for unknown or experimental targets 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
2023-08-14 08:39:10 +00:00
# We allow experimental targets that are not in LLVM_ALL_EXPERIMENTAL_TARGETS,
# as long as they are passed via LLVM_EXPERIMENTAL_TARGETS_TO_BUILD.
Escape LLVM_TARGETS_TO_BUILD while checking against LLVM_ALL_TARGETS and 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.
2023-11-01 07:34:23 +01:00
if ( NOT "${t}" IN_LIST LLVM_ALL_TARGETS AND NOT "${t}" IN_LIST LLVM_EXPERIMENTAL_TARGETS_TO_BUILD )
if( "${t}" IN_LIST LLVM_ALL_EXPERIMENTAL_TARGETS )
[llvm][CMake] Improve error message for unknown or experimental targets 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
2023-08-14 08:39:10 +00:00
message(FATAL_ERROR "The target `${t}' is experimental and must be passed "
"via LLVM_EXPERIMENTAL_TARGETS_TO_BUILD.")
else()
message(FATAL_ERROR "The target `${t}' is not a core tier target. It may be "
"experimental, if so it must be passed via "
"LLVM_EXPERIMENTAL_TARGETS_TO_BUILD.\n"
"Core tier targets: ${LLVM_ALL_TARGETS}\n"
"Known experimental targets: ${LLVM_ALL_EXPERIMENTAL_TARGETS}")
endif()
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
else()
set(LLVM_ENUM_TARGETS "${LLVM_ENUM_TARGETS}LLVM_TARGET(${t})\n")
Improve llvm-config.h to record which target is configured or not (#71164) 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.
2023-11-03 11:01:40 -07:00
string(TOUPPER ${t} T_UPPER)
set(LLVM_HAS_${T_UPPER}_TARGET 1)
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
endif()
file(GLOB asmp_file "${td}/*AsmPrinter.cpp")
if( asmp_file )
set(LLVM_ENUM_ASM_PRINTERS
"${LLVM_ENUM_ASM_PRINTERS}LLVM_ASM_PRINTER(${t})\n")
endif()
if( EXISTS ${td}/AsmParser/CMakeLists.txt )
set(LLVM_ENUM_ASM_PARSERS
"${LLVM_ENUM_ASM_PARSERS}LLVM_ASM_PARSER(${t})\n")
endif()
if( EXISTS ${td}/Disassembler/CMakeLists.txt )
set(LLVM_ENUM_DISASSEMBLERS
"${LLVM_ENUM_DISASSEMBLERS}LLVM_DISASSEMBLER(${t})\n")
endif()
[llvm-exegesis] Initialize all supported targets Enable registration of multiple exegesis targets at once. Use idiomatic approach to defining target select macros, but leave code in the llvm-mca sub-directories for now. This is a stepping stone towards allowing llvm-exegesis benchmarking via simulator or testing in non-target dependent tests. Differential Revision: https://reviews.llvm.org/D133605
2022-09-22 09:02:22 -07:00
if( EXISTS ${td}/MCA/CMakeLists.txt )
[MCA] Moving the target specific CustomBehaviour impl. from /tools/llvm-mca/ to /lib/Target/. Differential Revision: https://reviews.llvm.org/D106775
2021-07-24 20:27:41 -07:00
set(LLVM_ENUM_TARGETMCAS
"${LLVM_ENUM_TARGETMCAS}LLVM_TARGETMCA(${t})\n")
endif()
[llvm-exegesis] Initialize all supported targets Enable registration of multiple exegesis targets at once. Use idiomatic approach to defining target select macros, but leave code in the llvm-mca sub-directories for now. This is a stepping stone towards allowing llvm-exegesis benchmarking via simulator or testing in non-target dependent tests. Differential Revision: https://reviews.llvm.org/D133605
2022-09-22 09:02:22 -07:00
if( EXISTS ${LLVM_MAIN_SRC_DIR}/tools/llvm-exegesis/lib/${t}/CMakeLists.txt )
set(LLVM_ENUM_EXEGESIS
"${LLVM_ENUM_EXEGESIS}LLVM_EXEGESIS(${t})\n")
endif()
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
endforeach(t)
Re-apply "Only define LLVM_EXTERNAL_VISIBILITY when building libLLVM dylib" With a fix for BUILD_SHARED_LIBS. Original commit message: When building LLVM static libraries, we should not make symbols more visible than CMAKE_CXX_VISIBILITY_PRESET, since the goal may be to have a purely hidden llvm embedded in another library. Instead, we only define LLVM_EXTERNAL_VISIBILITY for the dynamic library build (when LLVM_BUILD_LLVM_DYLIB=YES or BUILD_SHARED_LIBS=YES). Original Review: https://reviews.llvm.org/D113610 Differential Revision: https://reviews.llvm.org/D115825
2021-12-10 11:49:04 -08:00
# Provide an LLVM_ namespaced alias for use in #cmakedefine.
set(LLVM_BUILD_SHARED_LIBS ${BUILD_SHARED_LIBS})
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
# Produce the target definition files, which provide a way for clients to easily
# include various classes of targets.
configure_file(
${LLVM_MAIN_INCLUDE_DIR}/llvm/Config/AsmPrinters.def.in
${LLVM_INCLUDE_DIR}/llvm/Config/AsmPrinters.def
)
configure_file(
${LLVM_MAIN_INCLUDE_DIR}/llvm/Config/AsmParsers.def.in
${LLVM_INCLUDE_DIR}/llvm/Config/AsmParsers.def
)
configure_file(
${LLVM_MAIN_INCLUDE_DIR}/llvm/Config/Disassemblers.def.in
${LLVM_INCLUDE_DIR}/llvm/Config/Disassemblers.def
)
configure_file(
${LLVM_MAIN_INCLUDE_DIR}/llvm/Config/Targets.def.in
${LLVM_INCLUDE_DIR}/llvm/Config/Targets.def
)
[MCA] Moving the target specific CustomBehaviour impl. from /tools/llvm-mca/ to /lib/Target/. Differential Revision: https://reviews.llvm.org/D106775
2021-07-24 20:27:41 -07:00
configure_file(
${LLVM_MAIN_INCLUDE_DIR}/llvm/Config/TargetMCAs.def.in
${LLVM_INCLUDE_DIR}/llvm/Config/TargetMCAs.def
)
[llvm-exegesis] Initialize all supported targets Enable registration of multiple exegesis targets at once. Use idiomatic approach to defining target select macros, but leave code in the llvm-mca sub-directories for now. This is a stepping stone towards allowing llvm-exegesis benchmarking via simulator or testing in non-target dependent tests. Differential Revision: https://reviews.llvm.org/D133605
2022-09-22 09:02:22 -07:00
configure_file(
${LLVM_MAIN_INCLUDE_DIR}/llvm/Config/TargetExegesis.def.in
${LLVM_INCLUDE_DIR}/llvm/Config/TargetExegesis.def
)
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
Guard `find_library(tensorflow_c_api ...)` by checking for TENSORFLOW_C_LIB_PATH to be set by the user 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
2020-09-28 20:46:22 +00:00
# They are not referenced. See set_output_directory().
[CMake] Avoid `LLVM_BINARY_DIR` when other more specific variable are better-suited, part 2 A simple sed doing these substitutions: - `${LLVM_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}\>` -> `${LLVM_LIBRARY_DIR}` - `${LLVM_BINARY_DIR}/bin\>` -> `${LLVM_TOOLS_BINARY_DIR}` where `\>` means "word boundary". The only manual modifications were reverting changes in - `runtimes/CMakeLists.txt` because these were "entry points" where we wanted to tread carefully not not introduce a "loop" which would end with an undefined variable being expanded to nothing. There are some `${LLVM_BINARY_DIR}/lib` without the `${LLVM_LIBDIR_SUFFIX}`, but these refer to the lib subdirectory of the source (`llvm/lib`). That `lib` is automatically appended to make the local `CMAKE_CURRENT_BINARY_DIR` value by `add_subdirectory`; since the directory name in the source tree is fixed without any suffix, the corresponding `CMAKE_CURRENT_BINARY_DIR` will also be. We therefore do not replace it but leave it as-is. This picks up where D133828 left off, getting the occurrences with*out* `CMAKE_CFG_INTDIR`. But this is difficult to do correctly and so not done in the (retroactively) previous diff. This hopefully increases readability overall, and also decreases the usages of `LLVM_LIBDIR_SUFFIX`, preparing us for D130586. Reviewed By: sebastian-ne Differential Revision: https://reviews.llvm.org/D132316
2022-09-14 00:12:04 -04:00
set( CMAKE_RUNTIME_OUTPUT_DIRECTORY ${LLVM_TOOLS_BINARY_DIR} )
set( CMAKE_LIBRARY_OUTPUT_DIRECTORY ${LLVM_LIBRARY_DIR} )
set( CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${LLVM_LIBRARY_DIR} )
Guard `find_library(tensorflow_c_api ...)` by checking for TENSORFLOW_C_LIB_PATH to be set by the user 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
2020-09-28 20:46:22 +00:00
[mlgo] Use TFLite for 'development' mode. TLite is a lightweight, statically linkable[1], model evaluator, supporting a subset of what the full tensorflow library does, sufficient for the types of scenarios we envision having. It is also faster. We still use saved models as "source of truth" - 'release' mode's AOT starts from a saved model; and the ML training side operates in terms of saved models. Using TFLite solves the following problems compared to using the full TF C API: - a compiler-friendly implementation for runtime-loadable (as opposed to AOT-embedded) models: it's statically linked; it can be built via cmake; - solves an issue we had when building the compiler with both AOT and full TF C API support, whereby, due to a packaging issue on the TF side, we needed to have the pip package and the TF C API library at the same version. We have no such constraints now. The main liability is it supporting a subset of what the full TF framework does. We do not expect that to cause an issue, but should that be the case, we can always revert back to using the full framework (after also figuring out a way to address the problems that motivated the move to TFLite). Details: This change switches the development mode to TFLite. Models are still expected to be placed in a directory - i.e. the parameters to clang don't change; what changes is the directory content: we still need an `output_spec.json` file; but instead of the saved_model protobuf and the `variables` directory, we now just have one file, `model.tflite`. The change includes a utility showing how to take a saved model and convert it to TFLite, which it uses for testing. The full TF implementation can still be built (not side-by-side). We intend to remove it shortly, after patching downstream dependencies. The build behavior, however, prioritizes TFLite - i.e. trying to enable both full TF C API and TFLite will just pick TFLite. [1] thanks to @petrhosek's changes to TFLite's cmake support and its deps!
2022-08-05 20:28:49 -07:00
# For up-to-date instructions for installing the TFLite dependency, refer to
[NFC] Inclusive language: Remove instances of master in URLs [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
2021-11-03 14:41:24 -05:00
# the bot setup script: https://github.com/google/ml-compiler-opt/blob/main/buildbot/buildbot_init.sh
[mlgo] Use TFLite for 'development' mode. TLite is a lightweight, statically linkable[1], model evaluator, supporting a subset of what the full tensorflow library does, sufficient for the types of scenarios we envision having. It is also faster. We still use saved models as "source of truth" - 'release' mode's AOT starts from a saved model; and the ML training side operates in terms of saved models. Using TFLite solves the following problems compared to using the full TF C API: - a compiler-friendly implementation for runtime-loadable (as opposed to AOT-embedded) models: it's statically linked; it can be built via cmake; - solves an issue we had when building the compiler with both AOT and full TF C API support, whereby, due to a packaging issue on the TF side, we needed to have the pip package and the TF C API library at the same version. We have no such constraints now. The main liability is it supporting a subset of what the full TF framework does. We do not expect that to cause an issue, but should that be the case, we can always revert back to using the full framework (after also figuring out a way to address the problems that motivated the move to TFLite). Details: This change switches the development mode to TFLite. Models are still expected to be placed in a directory - i.e. the parameters to clang don't change; what changes is the directory content: we still need an `output_spec.json` file; but instead of the saved_model protobuf and the `variables` directory, we now just have one file, `model.tflite`. The change includes a utility showing how to take a saved model and convert it to TFLite, which it uses for testing. The full TF implementation can still be built (not side-by-side). We intend to remove it shortly, after patching downstream dependencies. The build behavior, however, prioritizes TFLite - i.e. trying to enable both full TF C API and TFLite will just pick TFLite. [1] thanks to @petrhosek's changes to TFLite's cmake support and its deps!
2022-08-05 20:28:49 -07:00
set(LLVM_HAVE_TFLITE "" CACHE BOOL "Use tflite")
if (LLVM_HAVE_TFLITE)
find_package(tensorflow-lite REQUIRED)
[llvm][NFC] expose LLVM_HAVE_TF_API through llvm-config.h 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
2020-07-13 22:30:25 -07:00
endif()
[llvm][NFC] Remove definition from build system of LLVM_HAVE_TF_AOT 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
2020-07-22 11:16:08 -07:00
# For up-to-date instructions for installing the Tensorflow dependency, refer to
[NFC] Inclusive language: Remove instances of master in URLs [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
2021-11-03 14:41:24 -05:00
# the bot setup script: https://github.com/google/ml-compiler-opt/blob/main/buildbot/buildbot_init.sh
[llvm][NFC] Remove definition from build system of LLVM_HAVE_TF_AOT 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
2020-07-22 11:16:08 -07:00
# Specifically, assuming python3 is installed:
# python3 -m pip install --upgrade pip && python3 -m pip install --user tf_nightly==2.3.0.dev20200528
# Then set TENSORFLOW_AOT_PATH to the package install - usually it's ~/.local/lib/python3.7/site-packages/tensorflow
#
set(TENSORFLOW_AOT_PATH "" CACHE PATH "Path to TensorFlow pip install dir")
if (NOT TENSORFLOW_AOT_PATH STREQUAL "")
set(LLVM_HAVE_TF_AOT "ON" CACHE BOOL "Tensorflow AOT available")
set(TENSORFLOW_AOT_COMPILER
"${TENSORFLOW_AOT_PATH}/../../../../bin/saved_model_cli"
CACHE PATH "Path to the Tensorflow AOT compiler")
[mlgo] Remove the protobuf dependency The dependency was due to the log format. This change switches to the previously-introduced (D139370) "dependency-free" logger instead of the protobuf-based one. A subsequent change will clean out the unnecessary abstraction left behind. This change drops the logger unittest, we have sufficient test coverage via lit tests, and a unit test would require adding, unnecesarily, a log reader (the reader is expected to be python, for the ML side, and there is a reader for that under Analysis/models, used for tests). Differential Revision: https://reviews.llvm.org/D141720
2023-01-13 12:22:20 -08:00
include_directories(${TENSORFLOW_AOT_PATH}/include)
[llvm][NFC] Remove definition from build system of LLVM_HAVE_TF_AOT 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
2020-07-22 11:16:08 -07:00
add_subdirectory(${TENSORFLOW_AOT_PATH}/xla_aot_runtime_src
${CMAKE_ARCHIVE_OUTPUT_DIRECTORY}/tf_runtime)
[NFC] Trim trailing whitespaces in `llvm/CMakeLists.txt`
2021-08-16 12:49:59 -04:00
install(TARGETS tf_xla_runtime EXPORT LLVMExports
Revert "[cmake] Use `CMAKE_INSTALL_LIBDIR` too" This reverts commit f7a33090a91015836497c75f173775392ab0304d. Unfortunately this causes a number of failures that didn't show up in my local build.
2022-08-18 22:44:46 -04:00
ARCHIVE DESTINATION lib${LLVM_LIBDIR_SUFFIX} COMPONENT tf_xla_runtime)
[MLOpt] Add tf_xla_runtime to LLVMDevelopmentExport (#124610) We need to use tf on assert builds, thus requires it to be export as well. Signed-off-by: Peter Rong <PeterRong@meta.com>
2025-01-27 10:59:07 -08:00
install(TARGETS tf_xla_runtime EXPORT LLVMDevelopmentExports
ARCHIVE DESTINATION lib${LLVM_LIBDIR_SUFFIX} COMPONENT tf_xla_runtime)
[mlgo] fix build rules 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
2021-04-02 23:45:35 -07:00
set_property(GLOBAL APPEND PROPERTY LLVM_EXPORTS tf_xla_runtime)
[mlgo][aot] requrie the model is autogenerated for test determinism 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
2021-10-13 10:36:08 -07:00
# Once we add more modules, we should handle this more automatically.
[MLGO] Improved support for AOT cross-targeting scenarios The tensorflow AOT compiler can cross-target, but it can't run on (for example) arm64. We added earlier support where the AOT-ed header and object would be built on a separate builder and then passed at build time to a build host where the AOT compiler can't run, but clang can be otherwise built. To simplify such scenarios given we now support more than one AOT-able case (regalloc and inliner), we make the AOT scenario centered on whether files are generated, case by case (this includes the "passed from a different builder" scenario). This means we shouldn't need an 'umbrella' LLVM_HAVE_TF_AOT, in favor of case by case control. A builder can opt out of an AOT case by passing that case's model path as `none`. Note that the overrides still take precedence. This patch controls conditional compilation with case-specific flags, which can be enabled locally, for the component where those are available. We still keep an overall flag for some tests. The 'development/training' mode is unchanged, because there the model is passed from the command line and interpreted. Differential Revision: https://reviews.llvm.org/D117752
2022-01-19 21:19:53 -08:00
if (DEFINED LLVM_OVERRIDE_MODEL_HEADER_INLINERSIZEMODEL)
set(LLVM_INLINER_MODEL_PATH "none")
elseif(NOT DEFINED LLVM_INLINER_MODEL_PATH
[mlgo][aot] requrie the model is autogenerated for test determinism 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
2021-10-13 10:36:08 -07:00
OR "${LLVM_INLINER_MODEL_PATH}" STREQUAL ""
OR "${LLVM_INLINER_MODEL_PATH}" STREQUAL "autogenerate")
set(LLVM_INLINER_MODEL_PATH "autogenerate")
set(LLVM_INLINER_MODEL_AUTOGENERATED 1)
endif()
[MLGO] Improved support for AOT cross-targeting scenarios The tensorflow AOT compiler can cross-target, but it can't run on (for example) arm64. We added earlier support where the AOT-ed header and object would be built on a separate builder and then passed at build time to a build host where the AOT compiler can't run, but clang can be otherwise built. To simplify such scenarios given we now support more than one AOT-able case (regalloc and inliner), we make the AOT scenario centered on whether files are generated, case by case (this includes the "passed from a different builder" scenario). This means we shouldn't need an 'umbrella' LLVM_HAVE_TF_AOT, in favor of case by case control. A builder can opt out of an AOT case by passing that case's model path as `none`. Note that the overrides still take precedence. This patch controls conditional compilation with case-specific flags, which can be enabled locally, for the component where those are available. We still keep an overall flag for some tests. The 'development/training' mode is unchanged, because there the model is passed from the command line and interpreted. Differential Revision: https://reviews.llvm.org/D117752
2022-01-19 21:19:53 -08:00
if (DEFINED LLVM_OVERRIDE_MODEL_HEADER_REGALLOCEVICTMODEL)
set(LLVM_RAEVICT_MODEL_PATH "none")
elseif(NOT DEFINED LLVM_RAEVICT_MODEL_PATH
[MLGO] ML Regalloc Eviction Advisor The bulk of the implementation is common between 'release' mode (==AOT-ed model) and 'development' mode (for training), the main difference is that in development mode, we may also log features (for training logs), inject scoring information (currently after the Virtual Register Rewriter) and then produce the log file. This patch also introduces the score injection pass, 'Register Allocation Pass Scoring', which is trivially just logging the score in development mode. Differential Revision: https://reviews.llvm.org/D117147
2021-12-22 12:46:06 -08:00
OR "${LLVM_RAEVICT_MODEL_PATH}" STREQUAL ""
OR "${LLVM_RAEVICT_MODEL_PATH}" STREQUAL "autogenerate")
set(LLVM_RAEVICT_MODEL_PATH "autogenerate")
set(LLVM_RAEVICT_MODEL_AUTOGENERATED 1)
endif()
[llvm][NFC] Remove definition from build system of LLVM_HAVE_TF_AOT 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
2020-07-22 11:16:08 -07:00
endif()
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
# Configure the three LLVM configuration header files.
configure_file(
${LLVM_MAIN_INCLUDE_DIR}/llvm/Config/config.h.cmake
${LLVM_INCLUDE_DIR}/llvm/Config/config.h)
configure_file(
${LLVM_MAIN_INCLUDE_DIR}/llvm/Config/llvm-config.h.cmake
${LLVM_INCLUDE_DIR}/llvm/Config/llvm-config.h)
Add link-time detection of LLVM_ABI_BREAKING_CHECKS mismatch The macro LLVM_ENABLE_ABI_BREAKING_CHECKS is moved to a new header abi-breaking.h, from llvm-config.h. Only headers that are using the macro are including this new header. LLVM will define a symbol, either EnableABIBreakingChecks or DisableABIBreakingChecks depending on the configuration setting for LLVM_ABI_BREAKING_CHECKS. The abi-breaking.h header will add weak references to these symbols in every clients that includes this header. This should ensure that a mismatch triggers a link failure (or a load time failure for DSO). On MSVC, the pragma "detect_mismatch" is used instead. Differential Revision: https://reviews.llvm.org/D26876 llvm-svn: 288082
2016-11-28 22:23:53 +00:00
configure_file(
${LLVM_MAIN_INCLUDE_DIR}/llvm/Config/abi-breaking.h.cmake
${LLVM_INCLUDE_DIR}/llvm/Config/abi-breaking.h)
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
if(APPLE AND DARWIN_LTO_LIBRARY)
set(CMAKE_EXE_LINKER_FLAGS
"${CMAKE_EXE_LINKER_FLAGS} -Wl,-lto_library -Wl,${DARWIN_LTO_LIBRARY}")
set(CMAKE_SHARED_LINKER_FLAGS
"${CMAKE_SHARED_LINKER_FLAGS} -Wl,-lto_library -Wl,${DARWIN_LTO_LIBRARY}")
set(CMAKE_MODULE_LINKER_FLAGS
"${CMAKE_MODULE_LINKER_FLAGS} -Wl,-lto_library -Wl,${DARWIN_LTO_LIBRARY}")
endif()
Build with _XOPEN_SOURCE defined on AIX Summary: It is useful to build with _XOPEN_SOURCE defined on AIX, enabling X/Open and POSIX compatibility mode, to work around stray macros and other bugs in the headers provided by the system and build compiler. This patch adds the config to cmake to build with _XOPEN_SOURCE defined on AIX with a few exceptions. Google Test internals require access to platform specific thread info constructs on AIX so in that case we build with _ALL_SOURCE defined instead. Libclang also uses header which needs _ALL_SOURCE on AIX so we leave that as is as well. We also add building on AIX with the large file API and doing CMake header checks with X/OPEN definitions so the results are consistent with the environment that will be present in the build. Reviewers: hubert.reinterpretcast, xingxue, andusy Reviewed By: hubert.reinterpretcast Subscribers: mgorny, jsji, cfe-commits, llvm-commits Tags: #llvm, #clang Differential Revision: https://reviews.llvm.org/D62533 llvm-svn: 362808
2019-06-07 15:45:25 +00:00
# Build with _XOPEN_SOURCE on AIX, as stray macros in _ALL_SOURCE mode tend to
# break things. In this case we need to enable the large-file API as well.
if (UNIX AND ${CMAKE_SYSTEM_NAME} MATCHES "AIX")
Revert "[compiler-rt] Disable LLVM_ENABLE_PER_TARGET_RUNTIME_DIR=ON on AIX. (#131200)" (#132574) … This reverts commit 8e773d8a10cc996fbbe834f59ed9f7044c3539e0.
2025-03-22 20:56:47 -04:00
add_compile_definitions(_XOPEN_SOURCE=700)
add_compile_definitions(_LARGE_FILE_API)
add_compile_options(-pthread)
[AIX] Make sure we use export lists for plugins 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
2020-05-08 13:45:44 -04:00
[AIX][cmake] Adjust management of `-G` for linking The change in 0ba98433971f 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 0ba98433971f 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
2020-10-23 14:25:22 -04:00
# Modules should be built with -shared -Wl,-G, so we can use runtime linking
# with plugins.
string(APPEND CMAKE_MODULE_LINKER_FLAGS " -shared -Wl,-G")
[AIX] Make sure we use export lists for plugins 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
2020-05-08 13:45:44 -04:00
# Also set the correct flags for building shared libraries.
string(APPEND CMAKE_SHARED_LINKER_FLAGS " -shared")
Build with _XOPEN_SOURCE defined on AIX Summary: It is useful to build with _XOPEN_SOURCE defined on AIX, enabling X/Open and POSIX compatibility mode, to work around stray macros and other bugs in the headers provided by the system and build compiler. This patch adds the config to cmake to build with _XOPEN_SOURCE defined on AIX with a few exceptions. Google Test internals require access to platform specific thread info constructs on AIX so in that case we build with _ALL_SOURCE defined instead. Libclang also uses header which needs _ALL_SOURCE on AIX so we leave that as is as well. We also add building on AIX with the large file API and doing CMake header checks with X/OPEN definitions so the results are consistent with the environment that will be present in the build. Reviewers: hubert.reinterpretcast, xingxue, andusy Reviewed By: hubert.reinterpretcast Subscribers: mgorny, jsji, cfe-commits, llvm-commits Tags: #llvm, #clang Differential Revision: https://reviews.llvm.org/D62533 llvm-svn: 362808
2019-06-07 15:45:25 +00:00
endif()
[SystemZ/ZOS] Additions to the build system. 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
2020-07-09 14:17:33 +02:00
# Build with _XOPEN_SOURCE on z/OS.
if (CMAKE_SYSTEM_NAME MATCHES "OS390")
[cmake] Stop using add_definitions Since CMake 3.12 this has been superseded by add_compile_definitions and other commands. Differential Revision: https://reviews.llvm.org/D142363
2023-01-23 15:04:23 +00:00
add_compile_definitions(_XOPEN_SOURCE=600)
add_compile_definitions(_OPEN_SYS) # Needed for process information.
add_compile_definitions(_OPEN_SYS_FILE_EXT) # Needed for EBCDIC I/O.
[SystemZ/ZOS] Additions to the build system. (#74730) This change extend the CMake files with the necessary additions to build LLVM for z/OS.
2023-12-07 15:04:56 -05:00
add_compile_definitions(_EXT) # Needed for file data.
[SystemZ][z/OS] Fix macro (#74878) This fixes the macro syntax
2023-12-08 13:30:16 -05:00
add_compile_definitions(_UNIX03_THREADS) # Multithreading support.
[SystemZ][z/OS] Build in ASCII 64 bit mode on z/OS (#90630) Setting the correct build flags on z/OS to build LLVM as 64-bit ASCII application.
2024-05-01 08:13:10 -04:00
# Need to build LLVM as ASCII application.
# This can't be a global setting because other projects may
# need to be built in EBCDIC mode.
append("-fzos-le-char-mode=ascii" CMAKE_CXX_FLAGS CMAKE_C_FLAGS)
append("-m64" CMAKE_CXX_FLAGS CMAKE_C_FLAGS)
[SystemZ/ZOS] Additions to the build system. 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
2020-07-09 14:17:33 +02:00
endif()
[CMake] Define _FILE_OFFSET_BITS=64 on Solaris This is the compantion patch to https://reviews.llvm.org/D64482, needed to ensure that builds with host compilers that don't yet predefine _FILE_OFFSET_BITS=64 on Solaris succeed by always making the host and freshly built clang consistent. Tested on x86_64-pc-solaris2.11. Differential Revision: https://reviews.llvm.org/D64483 llvm-svn: 367304
2019-07-30 10:33:20 +00:00
# Build with _FILE_OFFSET_BITS=64 on Solaris to match g++ >= 9.
if (UNIX AND ${CMAKE_SYSTEM_NAME} MATCHES "SunOS")
[cmake] Stop using add_definitions Since CMake 3.12 this has been superseded by add_compile_definitions and other commands. Differential Revision: https://reviews.llvm.org/D142363
2023-01-23 15:04:23 +00:00
add_compile_definitions(_FILE_OFFSET_BITS=64)
[CMake] Define _FILE_OFFSET_BITS=64 on Solaris This is the compantion patch to https://reviews.llvm.org/D64482, needed to ensure that builds with host compilers that don't yet predefine _FILE_OFFSET_BITS=64 on Solaris succeed by always making the host and freshly built clang consistent. Tested on x86_64-pc-solaris2.11. Differential Revision: https://reviews.llvm.org/D64483 llvm-svn: 367304
2019-07-30 10:33:20 +00:00
endif()
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
set(CMAKE_INCLUDE_CURRENT_DIR ON)
include_directories( ${LLVM_INCLUDE_DIR} ${LLVM_MAIN_INCLUDE_DIR})
# when crosscompiling import the executable targets from a file
if(LLVM_USE_HOST_TOOLS)
include(CrossCompile)
[cmake] Convert the NATIVE llvm build process to be project agnostic lldb recently added a tablegen tool. In order to properly cross compile lldb standalone there needs to be a mechanism to generate the native lldb build, analgous to what's done for the NATIVE llvm build. Thus, we can simply modify this setup to allow for any project to be used. llvm-svn: 366514
2019-07-19 00:10:06 +00:00
llvm_create_cross_target(LLVM NATIVE "" Release)
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
endif(LLVM_USE_HOST_TOOLS)
if(LLVM_TARGET_IS_CROSSCOMPILE_HOST)
[CMake] Fix typo "Wraning" (NFC) Summary: The typo was added in https://reviews.llvm.org/rL247151. It should be "warning", not "wraning". llvm-svn: 314486
2017-09-29 02:48:07 +00:00
# Dummy use to avoid CMake Warning: Manually-specified variables were not used
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
# (this is a variable that CrossCompile sets on recursive invocations)
endif()
if( ${CMAKE_SYSTEM_NAME} MATCHES SunOS )
[Solaris] replace Solaris.h hack with a set of better hacks Summary: Got rid of unwieldy -include Solaris.h portability solution, replacing it with interposed header and moving endian defines into Host.h. Fixes PR28370. Reviewers: joerg, alekseyshl, mgorny Reviewed By: joerg Subscribers: llvm-commits, mgorny, ro, krytarowski Patch by Fedor Sergeev. Differential Revision: https://reviews.llvm.org/D3413 llvm-svn: 306002
2017-06-22 13:18:46 +00:00
# special hack for Solaris to handle crazy system sys/regset.h
include_directories("${LLVM_MAIN_INCLUDE_DIR}/llvm/Support/Solaris")
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
endif( ${CMAKE_SYSTEM_NAME} MATCHES SunOS )
# Make sure we don't get -rdynamic in every binary. For those that need it,
Reapply "[CMake] Fold export_executable_symbols_* into function args. (#101741)" (#102138) Fix the builds with LLVM_TOOL_LLVM_DRIVER_BUILD enabled. LLVM_ENABLE_EXPORTED_SYMBOLS_IN_EXECUTABLES is not completely compatible with export_executable_symbols as the later will be ignored if the previous is set to NO. Fix the issue by passing if symbols need to be exported to llvm_add_exectuable so the link flag can be determined directly without calling export_executable_symbols_* later.
2024-08-07 09:12:15 -07:00
# use EXPORT_SYMBOLS argument.
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
set(CMAKE_SHARED_LIBRARY_LINK_CXX_FLAGS "")
include(AddLLVM)
include(TableGen)
[CMake] Don't LTO optimize targets that aren't part of any distribution When using distributions, targets that aren't included in any distribution don't need to be as optimized as targets that are included since those targets are typically only used for tests. We might consider avoiding LTO for these targets altogether, see https://lists.llvm.org/pipermail/llvm-dev/2021-April/149843.html Differential Revision: https://reviews.llvm.org/D102732
2021-05-18 16:08:42 -07:00
include(LLVMDistributionSupport)
CMAKE: apply -O3 for mingw clang Differential Revision: https://reviews.llvm.org/D41596 llvm-svn: 324570
2018-02-08 07:13:17 +00:00
if( MINGW AND NOT "${CMAKE_CXX_COMPILER_ID}" MATCHES "Clang" )
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
# People report that -O3 is unreliable on MinGW. The traditional
# build also uses -O2 for that reason:
llvm_replace_compiler_option(CMAKE_CXX_FLAGS_RELEASE "-O3" "-O2")
endif()
Generalize "check-all" umbrella targets, use for check-clang-tools The mechanism behind "check-all" is recording params of add_lit_testsuite() calls in global variables LLVM_LIT_*, and then creating an extra suite with their union at the end. This avoids composing the check-* targets directly, which doesn't work well. We generalize this by allowing multiple families of variables LLVM_{name}_LIT_*: umbrella_lit_testsuite_begin(check-foo) ... test suites here will be added to LLVM_FOO_LIT_* variables ... umbrella_lit_testsuite_end(check-foo) (This also moves some implementation muck out of {llvm,clang}/CMakeLists.txt This patch also changes check-clang-tools to use be an umbrella test target, which means the clangd and clang-pseudo tests are included in it, along with the the other testsuites that already are (like check-clang-extra-clang-tidy). Differential Revision: https://reviews.llvm.org/D121838
2022-03-16 19:46:28 +01:00
if(LLVM_INCLUDE_TESTS)
umbrella_lit_testsuite_begin(check-all)
endif()
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
# Put this before tblgen. Else we have a circular dependence.
Try to fix a circular dependency in the modules build. llvm-svn: 280746
2016-09-06 20:16:19 +00:00
add_subdirectory(lib/Demangle)
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
add_subdirectory(lib/Support)
add_subdirectory(lib/TableGen)
add_subdirectory(utils/TableGen)
[Modules] Move modulemaps to header search directories. NFC intended. 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
2023-03-08 20:14:44 -08:00
add_subdirectory(include)
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
add_subdirectory(lib)
if( LLVM_INCLUDE_UTILS )
add_subdirectory(utils/FileCheck)
add_subdirectory(utils/PerfectShuffle)
add_subdirectory(utils/count)
add_subdirectory(utils/not)
[Clang][C++23] P2071 Named universal character escapes Implements [[ https://wg21.link/p2071r1 | P2071 Named Universal Character Escapes ]] - as an extension in all language mode, the patch not warn in c++23 mode will be done later once this paper is plenary approved (in July). We add * A code generator that transforms `UnicodeData.txt` and `NameAliases.txt` to a space efficient data structure that can be queried in `O(NameLength)` * A set of functions in `Unicode.h` to query that data, including * A function to find an exact match of a given Unicode character name * A function to perform a loose (ignoring case, space, underscore, medial hyphen) matching * A function returning the best matching codepoint for a given string per edit distance * Support of `\N{}` escape sequences in String and character Literals, with loose and typos diagnostics/fixits * Support of `\N{}` as UCN with loose matching diagnostics/fixits. Loose matching is considered an error to match closely the semantics of P2071. The generated data contributes to 280kB of data to the binaries. `UnicodeData.txt` and `NameAliases.txt` are not committed to the repository in this patch, and regenerating the data is a manual process. Reviewed By: tahonermann Differential Revision: https://reviews.llvm.org/D123064
2022-04-04 12:41:12 +02:00
add_subdirectory(utils/UnicodeData)
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
add_subdirectory(utils/yaml-bench)
[llvm][CMake] Move `split-file` from tools to utils It fittingly already makes use of add_llvm_utility during target creation and is usually only used in conjunction with other (test) related utilities such as FileCheck and not, which are already in utils. Differential Revision: https://reviews.llvm.org/D131713
2022-08-12 14:16:29 +02:00
add_subdirectory(utils/split-file)
[MLGO] Upstream the corpus extraction tooling (#72319) 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
2024-01-19 17:23:51 -08:00
add_subdirectory(utils/mlgo-utils)
[llvm] Include utils/unittest before projects and runtimes Include utils/unittest before projects and runtimes so that downstream projects can check for the existence of the llvm_gtest target. This is motivated by 9c6c4d675bd1 which fixes the stand-alone build configuration where LLVM_MAIN_SRC_DIR does not exist. Differential revision: https://reviews.llvm.org/D124314
2022-08-15 09:42:41 -07:00
if( LLVM_INCLUDE_TESTS )
[llvm] Revise IDE folder structure (#89741) 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.
2024-05-25 13:28:30 +02:00
set(LLVM_SUBPROJECT_TITLE "Third-Party/Google Test")
Move googletest to the third-party directory Rre-commit of 59052468c3e38cab15582cefbb5133fd4c2ffce5 with a typo fix in compiler-rt/CMakeLists.txt
2022-11-09 08:51:34 -08:00
add_subdirectory(${LLVM_THIRD_PARTY_DIR}/unittest ${CMAKE_CURRENT_BINARY_DIR}/third-party/unittest)
Reapply "[CMake] Fold export_executable_symbols_* into function args. (#101741)" (#102138) Fix the builds with LLVM_TOOL_LLVM_DRIVER_BUILD enabled. LLVM_ENABLE_EXPORTED_SYMBOLS_IN_EXECUTABLES is not completely compatible with export_executable_symbols as the later will be ignored if the previous is set to NO. Fix the issue by passing if symbols need to be exported to llvm_add_exectuable so the link flag can be determined directly without calling export_executable_symbols_* later.
2024-08-07 09:12:15 -07:00
set(LLVM_SUBPROJECT_TITLE)
[llvm] Include utils/unittest before projects and runtimes Include utils/unittest before projects and runtimes so that downstream projects can check for the existence of the llvm_gtest target. This is motivated by 9c6c4d675bd1 which fixes the stand-alone build configuration where LLVM_MAIN_SRC_DIR does not exist. Differential revision: https://reviews.llvm.org/D124314
2022-08-15 09:42:41 -07:00
endif()
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
else()
if ( LLVM_INCLUDE_TESTS )
message(FATAL_ERROR "Including tests when not building utils will not work.
[cmake] Fix typo. NFC llvm-svn: 346290
2018-11-07 02:22:59 +00:00
Either set LLVM_INCLUDE_UTILS to On, or set LLVM_INCLUDE_TESTS to Off.")
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
endif()
endif()
# Use LLVM_ADD_NATIVE_VISUALIZERS_TO_SOLUTION instead of LLVM_INCLUDE_UTILS because it is not really a util
if (LLVM_ADD_NATIVE_VISUALIZERS_TO_SOLUTION)
add_subdirectory(utils/LLVMVisualizers)
endif()
foreach( binding ${LLVM_BINDINGS_LIST} )
if( EXISTS "${LLVM_MAIN_SRC_DIR}/bindings/${binding}/CMakeLists.txt" )
add_subdirectory(bindings/${binding})
endif()
endforeach()
add_subdirectory(projects)
if( LLVM_INCLUDE_TOOLS )
add_subdirectory(tools)
endif()
[CMake] Provide an option to disable runtimes build This could be used to either disable the runtimes build altogether or avoid building them but still generate the build targets. Differential Revision: https://reviews.llvm.org/D31060 llvm-svn: 298653
2017-03-23 22:40:10 +00:00
if( LLVM_INCLUDE_RUNTIMES )
add_subdirectory(runtimes)
endif()
[CMake] Add LLVM runtimes directory Summary: There are a few LLVM projects that produce runtime libraries. Ideally runtime libraries should be built differently than other projects, specifically they should be built using the just-built toolchain. There is support for building compiler-rt in this way from the clang build. Moving this logic into the LLVM build is interesting because it provides a simpler way to extend the just-built toolchain to include LLD and the LLVM object file tools. Once this functionality is better fleshed out and tested we’ll want to encapsulate it in a module that can be used for clang standalone builds, and we’ll want to make it the default way to build compiler-rt. With this patch applied there is no immediate change in the build. Moving compiler-rt out from llvm/projects into llvm/runtimes enables the functionality. This code has a few improvements over the method provided by LLVM_BUILD_EXTERNAL_COMPILER_RT. Specifically the sub-ninja command is always invoked, so changes to compiler-rt source files will get built properly, so this patch can be used for iterative development with just-built tools. This first patch only works with compiler-rt. Support for other runtime projects will be coming in follow-up patches. Reviewers: chandlerc, bogner Subscribers: kubabrecka, llvm-commits Differential Revision: http://reviews.llvm.org/D20992 llvm-svn: 273620
2016-06-23 22:07:21 +00:00
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
if( LLVM_INCLUDE_EXAMPLES )
add_subdirectory(examples)
endif()
if( LLVM_INCLUDE_TESTS )
[unittest] Allow LLVM unit test to run under a wrapper program. (#66821) 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.
2023-10-17 11:15:46 -07:00
set(LLVM_GTEST_RUN_UNDER
"" CACHE STRING
"Define the wrapper program that LLVM unit tests should be run under.")
Re-revert "Refactor debuginfo-tests." This is still breaking greendragon. At this point I give up until someone can fix the greendragon bots, and I will probably abandon this effort in favor of using a private github repository. llvm-svn: 318722
2017-11-21 01:20:28 +00:00
if(EXISTS ${LLVM_MAIN_SRC_DIR}/projects/test-suite AND TARGET clang)
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
include(LLVMExternalProjectUtils)
Re-revert "Refactor debuginfo-tests." This is still breaking greendragon. At this point I give up until someone can fix the greendragon bots, and I will probably abandon this effort in favor of using a private github repository. llvm-svn: 318722
2017-11-21 01:20:28 +00:00
llvm_ExternalProject_Add(test-suite ${LLVM_MAIN_SRC_DIR}/projects/test-suite
USE_TOOLCHAIN
EXCLUDE_FROM_ALL
NO_INSTALL
ALWAYS_CLEAN)
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
endif()
Revert "[lit] Avoid copying llvm/utils/lit/tests/Inputs with lit site configs" This reverts r309602, check-lit still leaves Output directories in the source directory. llvm-svn: 309833
2017-08-02 17:16:25 +00:00
add_subdirectory(utils/lit)
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
add_subdirectory(test)
add_subdirectory(unittests)
We do not need google test utils if we disabled LLVM_INCLUDE_TESTS Fixes embedded uses of llvm where google testing framework is provided outside. llvm-svn: 305088
2017-06-09 16:37:39 +00:00
Build KillTheDoctor with mingw-w64 compiler-rt uses it in its lit tests. llvm-svn: 290357
2016-12-22 19:11:42 +00:00
if (WIN32)
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
# This utility is used to prevent crashing tests from calling Dr. Watson on
# Windows.
add_subdirectory(utils/KillTheDoctor)
endif()
Generalize "check-all" umbrella targets, use for check-clang-tools The mechanism behind "check-all" is recording params of add_lit_testsuite() calls in global variables LLVM_LIT_*, and then creating an extra suite with their union at the end. This avoids composing the check-* targets directly, which doesn't work well. We generalize this by allowing multiple families of variables LLVM_{name}_LIT_*: umbrella_lit_testsuite_begin(check-foo) ... test suites here will be added to LLVM_FOO_LIT_* variables ... umbrella_lit_testsuite_end(check-foo) (This also moves some implementation muck out of {llvm,clang}/CMakeLists.txt This patch also changes check-clang-tools to use be an umbrella test target, which means the clangd and clang-pseudo tests are included in it, along with the the other testsuites that already are (like check-clang-extra-clang-tidy). Differential Revision: https://reviews.llvm.org/D121838
2022-03-16 19:46:28 +01:00
umbrella_lit_testsuite_end(check-all)
get_property(LLVM_ALL_LIT_DEPENDS GLOBAL PROPERTY LLVM_ALL_LIT_DEPENDS)
get_property(LLVM_ALL_ADDITIONAL_TEST_DEPENDS
GLOBAL PROPERTY LLVM_ALL_ADDITIONAL_TEST_DEPENDS)
[llvm][compiler-rt] Connect lit dependencies to test-depends targets. (#81783) compiler-rt was creating the test-depends targets and trying to fill its dependencies with a variable, but the variable was empty because it was supposed to take its value from a property. The changes in this commit grab the value of the property and add them as dependencies. The changes in llvm are to remove the usage of `DEPENDS` arguments from `add_custom_target`, which according to the documentation is reserved for files/outputs created by `add_custom_command`. Use `add_dependencies` instead. This is similar to the changes introduced in 4eb84582344f97167b6a2b4cb1fb1d75ae07897e for runtimes.
2024-02-15 00:49:09 +01:00
add_custom_target(test-depends)
if(LLVM_ALL_LIT_DEPENDS OR LLVM_ALL_ADDITIONAL_TEST_DEPENDS)
add_dependencies(test-depends ${LLVM_ALL_LIT_DEPENDS} ${LLVM_ALL_ADDITIONAL_TEST_DEPENDS})
endif()
[llvm] Revise IDE folder structure (#89741) 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.
2024-05-25 13:28:30 +02:00
set_target_properties(test-depends PROPERTIES FOLDER "LLVM/Tests")
[runtimes] Add missing test dependencies to check-all (#75090) Re-apply 7f215b1380da49dccbf57da3040a40d25ed898f4, which was reverted in a9e3d232a520a17f098d4dc872c9591c565e7d36. The orginal commit uncovered a bug that was fixed by 4701f776d0f22dc0ff80a7d33ef3ae031eac9c2f. Fixes #58680
2023-12-13 11:43:40 -08:00
add_dependencies(check-all test-depends)
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
endif()
if (LLVM_INCLUDE_DOCS)
add_subdirectory(docs)
endif()
add_subdirectory(cmake/modules)
Resubmit "[lit] Force site configs to run before source-tree configs" This is a resubmission of r313270. It broke standalone builds of compiler-rt because we were not correctly generating the llvm-lit script in the standalone build directory. The fixes incorporated here attempt to find llvm/utils/llvm-lit from the source tree returned by llvm-config. If present, it will generate llvm-lit into the output directory. Regardless, the user can specify -DLLVM_EXTERNAL_LIT to point to a specific lit.py on their file system. This supports the use case of someone installing lit via a package manager. If it cannot find a source tree, and -DLLVM_EXTERNAL_LIT is either unspecified or invalid, then we print a warning that tests will not be able to run. Differential Revision: https://reviews.llvm.org/D37756 llvm-svn: 313407
2017-09-15 22:10:46 +00:00
# Do this last so that all lit targets have already been created.
if (LLVM_INCLUDE_UTILS)
add_subdirectory(utils/llvm-lit)
endif()
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
if (NOT LLVM_INSTALL_TOOLCHAIN_ONLY)
install(DIRECTORY include/llvm include/llvm-c
[llvm] Use `GNUInstallDirs` to support custom installation dirs This is the patch for LLVM proper in my series for adding GNUInstallDirs support in all project. Additionally: Create a new `CACHE STRING` variable, `LLVM_EXAMPLES_INSTALL_DIR`, to control where the examples are installed on analogy with the other variables. --- This patch supersedes D28234, which tried to do the same thing but hand-rolled without GNUInstallDirs. This patch nearly reverts commit 3 0fc88bf1dc15a72e2d9809d28019d386b7a7cc0, which was a revert of a prior attempt." (I had to add a space here or else Phabricator detects a reference cycle and won't let me do the form submit.) Reviewed By: compnerd Differential Revision: https://reviews.llvm.org/D100810
2021-12-11 01:36:24 +00:00
DESTINATION "${CMAKE_INSTALL_INCLUDEDIR}"
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
COMPONENT llvm-headers
FILES_MATCHING
PATTERN "*.def"
PATTERN "*.h"
PATTERN "*.td"
PATTERN "*.inc"
PATTERN "LICENSE.TXT"
)
Ensure that DataTypes.h is installed now that it's moved to llvm-c llvm-svn: 328130
2018-03-21 18:21:57 +00:00
install(DIRECTORY ${LLVM_INCLUDE_DIR}/llvm ${LLVM_INCLUDE_DIR}/llvm-c
[llvm] Use `GNUInstallDirs` to support custom installation dirs This is the patch for LLVM proper in my series for adding GNUInstallDirs support in all project. Additionally: Create a new `CACHE STRING` variable, `LLVM_EXAMPLES_INSTALL_DIR`, to control where the examples are installed on analogy with the other variables. --- This patch supersedes D28234, which tried to do the same thing but hand-rolled without GNUInstallDirs. This patch nearly reverts commit 3 0fc88bf1dc15a72e2d9809d28019d386b7a7cc0, which was a revert of a prior attempt." (I had to add a space here or else Phabricator detects a reference cycle and won't let me do the form submit.) Reviewed By: compnerd Differential Revision: https://reviews.llvm.org/D100810
2021-12-11 01:36:24 +00:00
DESTINATION "${CMAKE_INSTALL_INCLUDEDIR}"
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
COMPONENT llvm-headers
FILES_MATCHING
PATTERN "*.def"
PATTERN "*.h"
PATTERN "*.gen"
PATTERN "*.inc"
# Exclude include/llvm/CMakeFiles/intrinsics_gen.dir, matched by "*.def"
PATTERN "CMakeFiles" EXCLUDE
PATTERN "config.h" EXCLUDE
)
[LLVM] Allow modulemap installation Summary: Currently we can't install the modulemaps provided by LLVM, since they are not structured to support headers generated as part of the build (ex. `llvm/IR/Attributes.gen`). This patch restructures the module maps in order to support installation. Modules containing generated headers are defined in the new `module.extern.modulemap` file, and are referenced from the main `module.modulemap` using `extern module`. There are two versions of the `module.extern.modulemap` file; one used when building and another, `module.install.modulemap`, which is re-named during installation. Users can opt-into module map installation using `-DLLVM_INSTALL_MODULEMAPS=ON`. The default value is `OFF` due to llvm.org/PR31905. Reviewers: rsmith, mehdi_amini, bruno, EricWF Reviewed By: EricWF Subscribers: tschuett, chapuni, mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D53510 llvm-svn: 347420
2018-11-21 20:46:50 +00:00
if (LLVM_INSTALL_MODULEMAPS)
[Modules] Move modulemaps to header search directories. NFC intended. 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
2023-03-08 20:14:44 -08:00
install(DIRECTORY include
[llvm] Use `GNUInstallDirs` to support custom installation dirs This is the patch for LLVM proper in my series for adding GNUInstallDirs support in all project. Additionally: Create a new `CACHE STRING` variable, `LLVM_EXAMPLES_INSTALL_DIR`, to control where the examples are installed on analogy with the other variables. --- This patch supersedes D28234, which tried to do the same thing but hand-rolled without GNUInstallDirs. This patch nearly reverts commit 3 0fc88bf1dc15a72e2d9809d28019d386b7a7cc0, which was a revert of a prior attempt." (I had to add a space here or else Phabricator detects a reference cycle and won't let me do the form submit.) Reviewed By: compnerd Differential Revision: https://reviews.llvm.org/D100810
2021-12-11 01:36:24 +00:00
DESTINATION "${CMAKE_INSTALL_INCLUDEDIR}"
[LLVM] Allow modulemap installation Summary: Currently we can't install the modulemaps provided by LLVM, since they are not structured to support headers generated as part of the build (ex. `llvm/IR/Attributes.gen`). This patch restructures the module maps in order to support installation. Modules containing generated headers are defined in the new `module.extern.modulemap` file, and are referenced from the main `module.modulemap` using `extern module`. There are two versions of the `module.extern.modulemap` file; one used when building and another, `module.install.modulemap`, which is re-named during installation. Users can opt-into module map installation using `-DLLVM_INSTALL_MODULEMAPS=ON`. The default value is `OFF` due to llvm.org/PR31905. Reviewers: rsmith, mehdi_amini, bruno, EricWF Reviewed By: EricWF Subscribers: tschuett, chapuni, mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D53510 llvm-svn: 347420
2018-11-21 20:46:50 +00:00
COMPONENT llvm-headers
FILES_MATCHING
PATTERN "module.modulemap"
)
[Modules] Move modulemaps to header search directories. NFC intended. 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
2023-03-08 20:14:44 -08:00
install(FILES include/module.install.modulemap
DESTINATION "${CMAKE_INSTALL_INCLUDEDIR}"
[LLVM] Allow modulemap installation Summary: Currently we can't install the modulemaps provided by LLVM, since they are not structured to support headers generated as part of the build (ex. `llvm/IR/Attributes.gen`). This patch restructures the module maps in order to support installation. Modules containing generated headers are defined in the new `module.extern.modulemap` file, and are referenced from the main `module.modulemap` using `extern module`. There are two versions of the `module.extern.modulemap` file; one used when building and another, `module.install.modulemap`, which is re-named during installation. Users can opt-into module map installation using `-DLLVM_INSTALL_MODULEMAPS=ON`. The default value is `OFF` due to llvm.org/PR31905. Reviewers: rsmith, mehdi_amini, bruno, EricWF Reviewed By: EricWF Subscribers: tschuett, chapuni, mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D53510 llvm-svn: 347420
2018-11-21 20:46:50 +00:00
COMPONENT llvm-headers
RENAME "module.extern.modulemap"
)
endif(LLVM_INSTALL_MODULEMAPS)
cmake: Rename installhdrs to install-llvm-headers and fix the dependencies The installhdrs target was inconsistently named and would behave differently depending on whether or not you ran a build first. This renames it to install-llvm-headers to match other target names and adds a dependency on intrinsics_gen so that it will always install the same set of things. llvm-svn: 285035
2016-10-24 21:58:58 +00:00
# Installing the headers needs to depend on generating any public
# tablegen'd headers.
Fix missing build dependencies on omp_gen Differential Revision: https://reviews.llvm.org/D83003
2020-07-02 07:54:57 -06:00
add_custom_target(llvm-headers DEPENDS intrinsics_gen omp_gen)
[llvm] Revise IDE folder structure (#89741) 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.
2024-05-25 13:28:30 +02:00
set_target_properties(llvm-headers PROPERTIES FOLDER "LLVM/Resources")
cmake: Rename installhdrs to install-llvm-headers and fix the dependencies The installhdrs target was inconsistently named and would behave differently depending on whether or not you ran a build first. This renames it to install-llvm-headers to match other target names and adds a dependency on intrinsics_gen so that it will always install the same set of things. llvm-svn: 285035
2016-10-24 21:58:58 +00:00
[CMake] Use LLVM_ENABLE_IDE instead of CMAKE_CONFIGURATION_TYPES There are several places where we use CMAKE_CONFIGURATION_TYPES to determine if we are using an IDE generator and in turn decide not to generate some of the convenience targets (like all the install-* and check-llvm-* targets). This decision is made because IDEs don't always deal well with the thousands of targets LLVM can generate. This approach does not work for Visual Studio 15's new CMake integration. Because VS15 uses a Ninja generator, it isn't a multi-configuration build, and generating all these extra targets mucks up the UI and adds little value. With this change we still don't generate these targets by default for Visual Studio and Xcode generators, and LLVM_ENABLE_IDE becomes a switch that can be enabled on the VS15 CMake builds, to improve the IDE experience. This is a re-land of r340435, with a few minor fix-ups. The issues causing the revert were addressed in r344218, r344219, and r344553. llvm-svn: 344555
2018-10-15 21:20:02 +00:00
if (NOT LLVM_ENABLE_IDE)
[llvm] Add stripped installation targets CMake's generated installation scripts support `CMAKE_INSTALL_DO_STRIP` to enable stripping the installed binaries. LLVM's build system doesn't expose this option to the `install-` targets, but it's useful in conjunction with `install-distribution`. Add a new function to create the install targets, which creates both the regular install target and a second install target that strips during installation. Change the creation of all installation targets to use this new function. Stripping doesn't make a whole lot of sense for some installation targets (e.g. the LLVM headers), but consistency doesn't hurt. I'll make other repositories (e.g. clang, compiler-rt) use this in a follow-up, and then add an `install-distribution-stripped` target to actually accomplish the end goal of creating a stripped distribution. I don't want to do that step yet because the creation of that target would depend on the presence of the `install-*-stripped` target for each distribution component, and the distribution components from other repositories will be missing that target right now. Differential Revision: https://reviews.llvm.org/D40620 llvm-svn: 319480
2017-11-30 21:48:26 +00:00
add_llvm_install_targets(install-llvm-headers
[CMake] Fix dropped dependency in install-llvm-headers This dependency was accidentally dropped in r319480, causing install-distribution and install-llvm-headers to install an incomplete set of headers (the generated Intrinsics and Attributes would be missing). llvm-svn: 334452
2018-06-11 23:05:28 +00:00
DEPENDS llvm-headers
[llvm] Add stripped installation targets CMake's generated installation scripts support `CMAKE_INSTALL_DO_STRIP` to enable stripping the installed binaries. LLVM's build system doesn't expose this option to the `install-` targets, but it's useful in conjunction with `install-distribution`. Add a new function to create the install targets, which creates both the regular install target and a second install target that strips during installation. Change the creation of all installation targets to use this new function. Stripping doesn't make a whole lot of sense for some installation targets (e.g. the LLVM headers), but consistency doesn't hurt. I'll make other repositories (e.g. clang, compiler-rt) use this in a follow-up, and then add an `install-distribution-stripped` target to actually accomplish the end goal of creating a stripped distribution. I don't want to do that step yet because the creation of that target would depend on the presence of the `install-*-stripped` target for each distribution component, and the distribution components from other repositories will be missing that target right now. Differential Revision: https://reviews.llvm.org/D40620 llvm-svn: 319480
2017-11-30 21:48:26 +00:00
COMPONENT llvm-headers)
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
endif()
[CMake] Provide a custom target to install LLVM libraries This simplifies installing all LLVM libraries when doing component build; now you can include llvm-libraries in distribution components. Differential Revision: https://reviews.llvm.org/D51603 llvm-svn: 341395
2018-09-04 19:10:37 +00:00
# Custom target to install all libraries.
add_custom_target(llvm-libraries)
[llvm] Revise IDE folder structure (#89741) 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.
2024-05-25 13:28:30 +02:00
set_target_properties(llvm-libraries PROPERTIES FOLDER "LLVM/Resources")
[CMake] Provide a custom target to install LLVM libraries This simplifies installing all LLVM libraries when doing component build; now you can include llvm-libraries in distribution components. Differential Revision: https://reviews.llvm.org/D51603 llvm-svn: 341395
2018-09-04 19:10:37 +00:00
[CMake] Use LLVM_ENABLE_IDE instead of CMAKE_CONFIGURATION_TYPES There are several places where we use CMAKE_CONFIGURATION_TYPES to determine if we are using an IDE generator and in turn decide not to generate some of the convenience targets (like all the install-* and check-llvm-* targets). This decision is made because IDEs don't always deal well with the thousands of targets LLVM can generate. This approach does not work for Visual Studio 15's new CMake integration. Because VS15 uses a Ninja generator, it isn't a multi-configuration build, and generating all these extra targets mucks up the UI and adds little value. With this change we still don't generate these targets by default for Visual Studio and Xcode generators, and LLVM_ENABLE_IDE becomes a switch that can be enabled on the VS15 CMake builds, to improve the IDE experience. This is a re-land of r340435, with a few minor fix-ups. The issues causing the revert were addressed in r344218, r344219, and r344553. llvm-svn: 344555
2018-10-15 21:20:02 +00:00
if (NOT LLVM_ENABLE_IDE)
[CMake] Provide a custom target to install LLVM libraries This simplifies installing all LLVM libraries when doing component build; now you can include llvm-libraries in distribution components. Differential Revision: https://reviews.llvm.org/D51603 llvm-svn: 341395
2018-09-04 19:10:37 +00:00
add_llvm_install_targets(install-llvm-libraries
DEPENDS llvm-libraries
COMPONENT llvm-libraries)
endif()
get_property(LLVM_LIBS GLOBAL PROPERTY LLVM_LIBS)
if(LLVM_LIBS)
list(REMOVE_DUPLICATES LLVM_LIBS)
foreach(lib ${LLVM_LIBS})
add_dependencies(llvm-libraries ${lib})
[CMake] Fix a missing LLVM_ENABLE_IDE from r344555 This is just one place I missed swapping CMAKE_CONFIGURATION_TYPES with LLVM_ENABLE_IDE. llvm-svn: 344568
2018-10-15 22:36:59 +00:00
if (NOT LLVM_ENABLE_IDE)
[CMake] Provide a custom target to install LLVM libraries This simplifies installing all LLVM libraries when doing component build; now you can include llvm-libraries in distribution components. Differential Revision: https://reviews.llvm.org/D51603 llvm-svn: 341395
2018-09-04 19:10:37 +00:00
add_dependencies(install-llvm-libraries install-${lib})
[cmake] Fix -stripped for umbrella library install targets 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.
2020-03-20 18:42:09 -07:00
add_dependencies(install-llvm-libraries-stripped install-${lib}-stripped)
[CMake] Provide a custom target to install LLVM libraries This simplifies installing all LLVM libraries when doing component build; now you can include llvm-libraries in distribution components. Differential Revision: https://reviews.llvm.org/D51603 llvm-svn: 341395
2018-09-04 19:10:37 +00:00
endif()
endforeach()
endif()
dos2unix CMakeLists.txt The sign now reads "0 days since the last line ending confusion" llvm-svn: 264609
2016-03-28 18:19:32 +00:00
endif()
# This must be at the end of the LLVM root CMakeLists file because it must run
# after all targets are created.
build: extract LLVM distribution target handling This extracts the LLVM distribution target handling into a support module. Extraction will enable us to restructure the builds to support multiple distribution configurations (e.g. developer and user) to permit us to build the development package and the user package at once. llvm-svn: 363440
2019-06-14 18:28:57 +00:00
llvm_distribution_add_targets()
Fix compiler extension in standalone mode 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
2020-02-16 09:31:16 +01:00
process_llvm_pass_plugins(GEN_CONFIG)
[CMake] Add targets for generating coverage reports 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
2021-08-31 12:20:16 -07:00
include(CoverageReport)
This addresses LLDB bug 31699, which was caused by LLVM using static linking on Windows. In order to make sure that LLVM continues to work on machines that do not have the Universal CRT yet, we'll need to ship a copy of UCRT in the Windows installation package. Fortunately, CMake 3.6+ already supports app-local deployment of UCRT dlls, we just need to turn this on. Differential Revision: https://reviews.llvm.org/D29146 llvm-svn: 293373
2017-01-28 07:39:52 +00:00
# This allows us to deploy the Universal CRT DLLs by passing -DCMAKE_INSTALL_UCRT_LIBRARIES=ON to CMake
cmake: don't pack system libs unless CMAKE_INSTALL_UCRT_LIBRARIES is set (PR38476) llvm-svn: 339319
2018-08-09 08:41:03 +00:00
if (MSVC AND CMAKE_HOST_SYSTEM_NAME STREQUAL "Windows" AND CMAKE_INSTALL_UCRT_LIBRARIES)
This addresses LLDB bug 31699, which was caused by LLVM using static linking on Windows. In order to make sure that LLVM continues to work on machines that do not have the Universal CRT yet, we'll need to ship a copy of UCRT in the Windows installation package. Fortunately, CMake 3.6+ already supports app-local deployment of UCRT dlls, we just need to turn this on. Differential Revision: https://reviews.llvm.org/D29146 llvm-svn: 293373
2017-01-28 07:39:52 +00:00
include(InstallRequiredSystemLibraries)
endif()
Pull google/benchmark library to the LLVM tree This patch pulls google/benchmark v1.4.1 into the LLVM tree so that any project could use it for benchmark generation. A dummy benchmark is added to `llvm/benchmarks/DummyYAML.cpp` to validate the correctness of the build process. The current version does not utilize LLVM LNT and LLVM CMake infrastructure, but that might be sufficient for most users. Two introduced CMake variables: * `LLVM_INCLUDE_BENCHMARKS` (`ON` by default) generates benchmark targets * `LLVM_BUILD_BENCHMARKS` (`OFF` by default) adds generated benchmark targets to the list of default LLVM targets (i.e. if `ON` benchmarks will be built upon standard build invocation, e.g. `ninja` or `make` with no specific targets) List of modifications: * `BENCHMARK_ENABLE_TESTING` is disabled * `BENCHMARK_ENABLE_EXCEPTIONS` is disabled * `BENCHMARK_ENABLE_INSTALL` is disabled * `BENCHMARK_ENABLE_GTEST_TESTS` is disabled * `BENCHMARK_DOWNLOAD_DEPENDENCIES` is disabled Original discussion can be found here: http://lists.llvm.org/pipermail/llvm-dev/2018-August/125023.html Reviewed by: dberris, lebedev.ri Subscribers: ilya-biryukov, ioeric, EricWF, lebedev.ri, srhines, dschuff, mgorny, krytarowski, fedor.sergeev, mgrang, jfb, llvm-commits Differential Revision: https://reviews.llvm.org/D50894 llvm-svn: 340809
2018-08-28 09:42:41 +00:00
if (LLVM_INCLUDE_BENCHMARKS)
# Override benchmark defaults so that when the library itself is updated these
# modifications are not lost.
set(BENCHMARK_ENABLE_TESTING OFF CACHE BOOL "Disable benchmark testing" FORCE)
set(BENCHMARK_ENABLE_EXCEPTIONS OFF CACHE BOOL "Disable benchmark exceptions" FORCE)
set(BENCHMARK_ENABLE_INSTALL OFF CACHE BOOL "Don't install benchmark" FORCE)
set(BENCHMARK_DOWNLOAD_DEPENDENCIES OFF CACHE BOOL "Don't download dependencies" FORCE)
set(BENCHMARK_ENABLE_GTEST_TESTS OFF CACHE BOOL "Disable Google Test in benchmark" FORCE)
[CMake] Make omitting CMAKE_BUILD_TYPE an error After a lot of discussion in this diff the consensus was that it is really hard to guess the users intention with their LLVM build. Instead of trying to guess if Debug or Release is the correct default option we opted for just not specifying CMAKE_BUILD_TYPE a error. Discussion on discourse here: https://discourse.llvm.org/t/rfc-select-a-better-linker-by-default-or-warn-about-using-bfd Reviewed By: hans, mehdi_amini, aaron.ballman, jhenderson, MaskRay, awarzynski Differential Revision: https://reviews.llvm.org/D124153
2022-04-29 11:42:06 +02:00
set(BENCHMARK_ENABLE_WERROR ${LLVM_ENABLE_WERROR} CACHE BOOL
[benchmark] Pull latest; disable -Werror Pulled the latest (b000672), which adds an option to disable -Werror, which caused issues previously (see for instance https://reviews.llvm.org/D112012) Applied https://github.com/google/benchmark/pull/1305 to unblock, as this issue is causing downstream buildbot failures. The only change is in llvm/CMakeLists.txt, where we set BENCHMARK_ENABLE_WERROR to have the same value as LLVM_ENABLE_WERROR. This patch also introduces a convenience script to pull benchmark from upstream. Differential Revision: https://reviews.llvm.org/D115684
2021-12-13 16:02:02 -08:00
"Handle -Werror for Google Benchmark based on LLVM_ENABLE_WERROR" FORCE)
[benchmark] Fix buildbots failing to identify regex support This is cleanup after newly introduced google/benchmark library (rL340809). Many buildbots fail to identify regex engine support, so this should presumably fix the issue. llvm-svn: 340827
2018-08-28 14:51:09 +00:00
# Since LLVM requires C++11 it is safe to assume that std::regex is available.
set(HAVE_STD_REGEX ON CACHE BOOL "OK" FORCE)
[CMake] Make omitting CMAKE_BUILD_TYPE an error After a lot of discussion in this diff the consensus was that it is really hard to guess the users intention with their LLVM build. Instead of trying to guess if Debug or Release is the correct default option we opted for just not specifying CMAKE_BUILD_TYPE a error. Discussion on discourse here: https://discourse.llvm.org/t/rfc-select-a-better-linker-by-default-or-warn-about-using-bfd Reviewed By: hans, mehdi_amini, aaron.ballman, jhenderson, MaskRay, awarzynski Differential Revision: https://reviews.llvm.org/D124153
2022-04-29 11:42:06 +02:00
add_subdirectory(${LLVM_THIRD_PARTY_DIR}/benchmark
Re-Reland "[benchmarks] Move libcxx's fork of google/benchmark and llvm/utils'" This reverts commit b2fbd45d2395f1f6ef39db72b7156724fc101e40. D114922 fixed the reason of the 2nd revert. This patch also re-applies 39e9f5d3685f3cfca0df072928ad96d973704dff. Differential Revision: https://reviews.llvm.org/D112012
2021-12-07 16:46:55 -08:00
${CMAKE_CURRENT_BINARY_DIR}/third-party/benchmark)
[llvm] Revise IDE folder structure (#89741) 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.
2024-05-25 13:28:30 +02:00
set_target_properties(benchmark PROPERTIES FOLDER "Third-Party/Google Benchmark")
set_target_properties(benchmark_main PROPERTIES FOLDER "Third-Party/Google Benchmark")
Pull google/benchmark library to the LLVM tree This patch pulls google/benchmark v1.4.1 into the LLVM tree so that any project could use it for benchmark generation. A dummy benchmark is added to `llvm/benchmarks/DummyYAML.cpp` to validate the correctness of the build process. The current version does not utilize LLVM LNT and LLVM CMake infrastructure, but that might be sufficient for most users. Two introduced CMake variables: * `LLVM_INCLUDE_BENCHMARKS` (`ON` by default) generates benchmark targets * `LLVM_BUILD_BENCHMARKS` (`OFF` by default) adds generated benchmark targets to the list of default LLVM targets (i.e. if `ON` benchmarks will be built upon standard build invocation, e.g. `ninja` or `make` with no specific targets) List of modifications: * `BENCHMARK_ENABLE_TESTING` is disabled * `BENCHMARK_ENABLE_EXCEPTIONS` is disabled * `BENCHMARK_ENABLE_INSTALL` is disabled * `BENCHMARK_ENABLE_GTEST_TESTS` is disabled * `BENCHMARK_DOWNLOAD_DEPENDENCIES` is disabled Original discussion can be found here: http://lists.llvm.org/pipermail/llvm-dev/2018-August/125023.html Reviewed by: dberris, lebedev.ri Subscribers: ilya-biryukov, ioeric, EricWF, lebedev.ri, srhines, dschuff, mgorny, krytarowski, fedor.sergeev, mgrang, jfb, llvm-commits Differential Revision: https://reviews.llvm.org/D50894 llvm-svn: 340809
2018-08-28 09:42:41 +00:00
add_subdirectory(benchmarks)
endif()
Reland "[utils] Implement the llvm-locstats tool" The tool reports verbose output for the DWARF debug location coverage. The llvm-locstats for each variable or formal parameter DIE computes what percentage from the code section bytes, where it is in scope, it has location description. The line 0 shows the number (and the percentage) of DIEs with no location information, but the line 100 shows the number (and the percentage) of DIEs where there is location information in all code section bytes (where the variable or parameter is in the scope). The line 50..59 shows the number (and the percentage) of DIEs where the location information is in between 50 and 59 percentage of its scope covered. Differential Revision: https://reviews.llvm.org/D66526 The cause of the test failure was resolved. llvm-svn: 373427
2019-10-02 07:00:01 +00:00
if (LLVM_INCLUDE_UTILS AND LLVM_INCLUDE_TOOLS)
add_subdirectory(utils/llvm-locstats)
endif()
[cmake][llvm] Limit the number of Xcode schemes created by default (#101243) CMake -GXcode would otherwise offer to create one scheme for each target, which ends up being a lot. For now, limit the default to the `check-*` LIT targets, plus `ALL_BUILD` and `install`. For targets that aren't in the default list, we now have a configuration variable to promote an extra list of targets into schemes, for example `-DLLVM_XCODE_EXTRA_TARGET_SCHEMES="TargetParserTests;SupportTests"` to add schemes for `TargetParserTests` and `SupportTests` respectively.
2024-07-30 17:17:04 -07:00
if (XCODE)
# For additional targets that you would like to add schemes, specify e.g:
#
# -DLLVM_XCODE_EXTRA_TARGET_SCHEMES="TargetParserTests;SupportTests"
#
# at CMake configure time.
set(LLVM_XCODE_EXTRA_TARGET_SCHEMES "" CACHE STRING "Specifies an extra list of targets to turn into schemes")
foreach(target ${LLVM_XCODE_EXTRA_TARGET_SCHEMES})
set_target_properties(${target} PROPERTIES XCODE_GENERATE_SCHEME ON)
endforeach()
endif()
Reference in New Issue Copy Permalink