maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/cmake/modules/HandleLLVMOptions.cmake

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

1095 lines
48 KiB
CMake
Raw Normal View History

build/cmake: Move all the user controllable options into top-level CMakeLists for consistency. llvm-svn: 143728
2011-11-05 03:04:35 +08:00
# This CMake module is responsible for interpreting the user defined LLVM_
# options and executing the appropriate CMake commands to realize the users'
# selections.
Provide missing definition of uppercase_CMAKE_BUILD_TYPE in HandleLLVMOptions module llvm-svn: 222082
2014-11-15 15:45:31 +08:00
# This is commonly needed so make sure it's defined before we include anything
# else.
string(TOUPPER "${CMAKE_BUILD_TYPE}" uppercase_CMAKE_BUILD_TYPE)
[cmake] Check the compiler version first Otherwise users get messages from CheckAtomic about missing libatomic instead of a sensible message that says "use GCC 4.7 or newer". I structured the change along the lines of HandleLLVMStdlib.cmake, so that the standalone build of Clang still gets the compiler version check. Reviewers: beanz Differential Revision: http://reviews.llvm.org/D17789 llvm-svn: 262491
2016-03-03 00:42:56 +08:00
include(CheckCompilerVersion)
[CMake] Move -stdlib=libc++ handling into its own file. r200744 moved this into cmake/config-ix.cmake, so that it would happen very early in the build process. However, standalone builds of Clang and other external projects never include this file (which is correct). Now, -stdlib=libc++ and the LLVM_COMPILER_IS_GCC_COMPATIBLE option are both set in a new include file, HandleLLVMStdlib, which is included by both config-ix.cmake and HandleLLVMOptions.cmake. This preserves existing behavior for projects relying on HandleLLVMOptions and still does the right thing for builds of LLVM itself. llvm-svn: 200811
2014-02-05 08:02:37 +08:00
include(HandleLLVMStdlib)
Removing SUPPORTS_COVERED_SWITCH_DEFAULT_FLAG Adding CXX_SUPPORTS_COVERED_SWITCH_DEFAULT_FLAG C_SUPPORTS_COVERED_SWITCH_DEFAULT_FLAG This is to handle the wackiness on a Mac host where cmake detects: CMAKE_CXX_COMPILER == "/usr/bin/c++" CMAKE_C_COMPILER == "/usr/bin/gcc" llvm-svn: 168577
2012-11-26 10:02:08 +08:00
include(CheckCCompilerFlag)
CMake: Always include the CheckCXXCompilerFlag in HandleLLVMOptions.cmake. Previously we relied on it being included by config-ix.cmake. llvm-svn: 176396
2013-03-02 09:00:40 +08:00
include(CheckCXXCompilerFlag)
Fix builds with llvm/runtimes/compiler-rt after r354365 Compiler-rt doesn't include config-ix which was providing CheckSymbolExists to the LLVM build. Add it to HandleLLVMOptions to fix this llvm-svn: 354389
2019-02-20 06:02:38 +08:00
include(CheckSymbolExists)
[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-09 01:45:44 +08:00
include(CMakeDependentOption)
Changes for building Clang and others using LLVM as an external library. Installs tblgen (required by Clang). Translates handling of user settings and platform-dependant options to its own file, where it can included by another project. Installs the .cmake files required by projects like Clang. llvm-svn: 124816
2011-02-04 04:57:36 +08:00
[CMake] Properly handle the LTO cache arguments for MinGW We want to make sure that LINKER_IS_LLD_LINK is properly set - in this case it shouldn't be set when building for MinGW. Then we want to make the test for it correct and finally include the option to build with thinlto cache since the MinGW driver now supports that. Differential Revision: https://reviews.llvm.org/D80493
2020-05-25 15:28:17 +08:00
if(CMAKE_LINKER MATCHES "lld-link" OR (MSVC AND (LLVM_USE_LINKER STREQUAL "lld" OR LLVM_ENABLE_LLD)))
enable building with LTO on Windows using clang-cl and lld Summary: With clang-cl gaining support for link-time optimization, we can now enable builds using LTO when using clang-cl and lld on Windows. To do this, we must not pass the -flto flag to the linker; lld-link does not understand it, but will perform LTO automatically when it encounters bitcode files. We also don't pass /Brepro when using LTO - the compiler doesn't generate object files for LTO, so passing the flag would only result in a warning about it being unused. Reviewers: rnk, ruiu, hans Reviewed By: hans Subscribers: mgorny, mehdi_amini, llvm-commits Differential Revision: https://reviews.llvm.org/D30240 llvm-svn: 296658
2017-03-02 03:22:18 +08:00
set(LINKER_IS_LLD_LINK TRUE)
else()
set(LINKER_IS_LLD_LINK FALSE)
endif()
limit to 2 parallel links when using thinlto Summary: When using ThinLTO, the linker performs its own parallelism. This change limits the number of parallel link jobs that Ninja will issue to keep the total number of threads reasonable when linking with ThinLTO. Reviewers: hans, ruiu Subscribers: mgorny, mehdi_amini, Prazek Differential Revision: https://reviews.llvm.org/D31990 llvm-svn: 301676
2017-04-29 04:17:15 +08:00
set(LLVM_ENABLE_LTO OFF CACHE STRING "Build LLVM with LTO. May be specified as Thin or Full to use a particular kind of LTO")
string(TOUPPER "${LLVM_ENABLE_LTO}" uppercase_LLVM_ENABLE_LTO)
[CMake] Move ninja job pool options to HandleLLVMOptions Moving the Ninja job pool configuration settings into the HandleLLVMOptions module will allow standalone builds of LLVM sub-projects to use the LLVM options without needing to re-implement them. llvm-svn: 294334
2017-02-08 03:06:22 +08:00
# Ninja Job Pool support
# The following only works with the Ninja generator in CMake >= 3.0.
set(LLVM_PARALLEL_COMPILE_JOBS "" CACHE STRING
[CMake] NFC. Updating documentation on options The Ninja pool options are only supported with the Ninja generator and should be called out as such. llvm-svn: 344188
2018-10-11 05:36:12 +08:00
"Define the maximum number of concurrent compilation jobs (Ninja only).")
[CMake] Move ninja job pool options to HandleLLVMOptions Moving the Ninja job pool configuration settings into the HandleLLVMOptions module will allow standalone builds of LLVM sub-projects to use the LLVM options without needing to re-implement them. llvm-svn: 294334
2017-02-08 03:06:22 +08:00
if(LLVM_PARALLEL_COMPILE_JOBS)
[cmake] Use CMAKE_GENERATOR to determine if Ninja is used The name of the make program does not necessarily match "ninja", especially if an alternative implementation like samurai is used. Using CMAKE_GENERATOR is a more robust detection method, and is already used elsewhere in this file. Differential revision: https://reviews.llvm.org/D77091
2020-07-08 18:42:39 +08:00
if(NOT CMAKE_GENERATOR STREQUAL "Ninja")
[CMake] Move ninja job pool options to HandleLLVMOptions Moving the Ninja job pool configuration settings into the HandleLLVMOptions module will allow standalone builds of LLVM sub-projects to use the LLVM options without needing to re-implement them. llvm-svn: 294334
2017-02-08 03:06:22 +08:00
message(WARNING "Job pooling is only available with Ninja generators.")
else()
set_property(GLOBAL APPEND PROPERTY JOB_POOLS compile_job_pool=${LLVM_PARALLEL_COMPILE_JOBS})
set(CMAKE_JOB_POOL_COMPILE compile_job_pool)
endif()
endif()
set(LLVM_PARALLEL_LINK_JOBS "" CACHE STRING
[CMake] NFC. Updating documentation on options The Ninja pool options are only supported with the Ninja generator and should be called out as such. llvm-svn: 344188
2018-10-11 05:36:12 +08:00
"Define the maximum number of concurrent link jobs (Ninja only).")
[cmake] Use CMAKE_GENERATOR to determine if Ninja is used The name of the make program does not necessarily match "ninja", especially if an alternative implementation like samurai is used. Using CMAKE_GENERATOR is a more robust detection method, and is already used elsewhere in this file. Differential revision: https://reviews.llvm.org/D77091
2020-07-08 18:42:39 +08:00
if(CMAKE_GENERATOR STREQUAL "Ninja")
limit to 2 parallel links when using thinlto Summary: When using ThinLTO, the linker performs its own parallelism. This change limits the number of parallel link jobs that Ninja will issue to keep the total number of threads reasonable when linking with ThinLTO. Reviewers: hans, ruiu Subscribers: mgorny, mehdi_amini, Prazek Differential Revision: https://reviews.llvm.org/D31990 llvm-svn: 301676
2017-04-29 04:17:15 +08:00
if(NOT LLVM_PARALLEL_LINK_JOBS AND uppercase_LLVM_ENABLE_LTO STREQUAL "THIN")
message(STATUS "ThinLTO provides its own parallel linking - limiting parallel link jobs to 2.")
set(LLVM_PARALLEL_LINK_JOBS "2")
endif()
if(LLVM_PARALLEL_LINK_JOBS)
[CMake] Move ninja job pool options to HandleLLVMOptions Moving the Ninja job pool configuration settings into the HandleLLVMOptions module will allow standalone builds of LLVM sub-projects to use the LLVM options without needing to re-implement them. llvm-svn: 294334
2017-02-08 03:06:22 +08:00
set_property(GLOBAL APPEND PROPERTY JOB_POOLS link_job_pool=${LLVM_PARALLEL_LINK_JOBS})
set(CMAKE_JOB_POOL_LINK link_job_pool)
endif()
limit to 2 parallel links when using thinlto Summary: When using ThinLTO, the linker performs its own parallelism. This change limits the number of parallel link jobs that Ninja will issue to keep the total number of threads reasonable when linking with ThinLTO. Reviewers: hans, ruiu Subscribers: mgorny, mehdi_amini, Prazek Differential Revision: https://reviews.llvm.org/D31990 llvm-svn: 301676
2017-04-29 04:17:15 +08:00
elseif(LLVM_PARALLEL_LINK_JOBS)
message(WARNING "Job pooling is only available with Ninja generators.")
[CMake] Move ninja job pool options to HandleLLVMOptions Moving the Ninja job pool configuration settings into the HandleLLVMOptions module will allow standalone builds of LLVM sub-projects to use the LLVM options without needing to re-implement them. llvm-svn: 294334
2017-02-08 03:06:22 +08:00
endif()
Changes for building Clang and others using LLVM as an external library. Installs tblgen (required by Clang). Translates handling of user settings and platform-dependant options to its own file, where it can included by another project. Installs the .cmake files required by projects like Clang. llvm-svn: 124816
2011-02-04 04:57:36 +08:00
if( LLVM_ENABLE_ASSERTIONS )
# MSVC doesn't like _DEBUG on release builds. See PR 4379.
if( NOT MSVC )
add_definitions( -D_DEBUG )
endif()
Tweak the cmake interaction between CMAKE_BUILD_TYPE and LLVM_ENABLE_ASSERTIONS. The issue is that CMAKE_BUILD_TYPE=RelWithDebInfo LLVM_ENABLE_ASSERTIONS=ON was not building with assertions enabled. (I was unable to find what in the LLVM source tree was adding -DNDEBUG to the build line in this case, so decided that it must be cmake itself that was adding it - this may depend on the cmake version). The fix treats any mode that is not Debug as being the same as Release for this purpose (previously it was being assumed that cmake would only add -DNDEBUG for Release and not for RelWithDebInfo or MinSizeRel). If other versions of cmake don't add -DNDEBUG for RelWithDebInfo then that's OK: with this change you just get a useless but harmless -UNDEBUG or -DNDEBUG. llvm-svn: 186499
2013-07-17 17:34:51 +08:00
# On non-Debug builds cmake automatically defines NDEBUG, so we
Changes for building Clang and others using LLVM as an external library. Installs tblgen (required by Clang). Translates handling of user settings and platform-dependant options to its own file, where it can included by another project. Installs the .cmake files required by projects like Clang. llvm-svn: 124816
2011-02-04 04:57:36 +08:00
# explicitly undefine it:
Tweak the cmake interaction between CMAKE_BUILD_TYPE and LLVM_ENABLE_ASSERTIONS. The issue is that CMAKE_BUILD_TYPE=RelWithDebInfo LLVM_ENABLE_ASSERTIONS=ON was not building with assertions enabled. (I was unable to find what in the LLVM source tree was adding -DNDEBUG to the build line in this case, so decided that it must be cmake itself that was adding it - this may depend on the cmake version). The fix treats any mode that is not Debug as being the same as Release for this purpose (previously it was being assumed that cmake would only add -DNDEBUG for Release and not for RelWithDebInfo or MinSizeRel). If other versions of cmake don't add -DNDEBUG for RelWithDebInfo then that's OK: with this change you just get a useless but harmless -UNDEBUG or -DNDEBUG. llvm-svn: 186499
2013-07-17 17:34:51 +08:00
if( NOT uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG" )
build: only pass -UNDEBUG when compiling C/C++ This patch limits adding -UNDEBUG to C and C++ files so that projects can include files compiled with compilers that don't recognize this argument (Swift e.g.). add_definitions does not expand generators, hence the change from add_definitions to add_compile_options. Patch by Evan Wilde!
2020-02-03 02:49:03 +08:00
# NOTE: use `add_compile_options` rather than `add_definitions` since
# `add_definitions` does not support generator expressions.
build: attempt to repair the build The change in 9b84dabc5f36f7e027c62b5c00ea97e21cfcacdd uses a newer syntax which not all the builders support. Use an explicit `OR` over the languages instead to repair the builders.
2020-02-03 08:18:00 +08:00
add_compile_options($<$<OR:$<COMPILE_LANGUAGE:C>,$<COMPILE_LANGUAGE:CXX>>:-UNDEBUG>)
build: only pass -UNDEBUG when compiling C/C++ This patch limits adding -UNDEBUG to C and C++ files so that projects can include files compiled with compilers that don't recognize this argument (Swift e.g.). add_definitions does not expand generators, hence the change from add_definitions to add_compile_options. Patch by Evan Wilde!
2020-02-03 02:49:03 +08:00
[cmake] Avoid rel+asserts warnings when passing -UNDEBUG MSVC 2012 gives warning D9025, "overriding /D NDEBUG with -UNDEBUG". Removing the original definition of NDEBUG silences this. llvm-svn: 178967
2013-04-07 09:45:01 +08:00
# Also remove /D NDEBUG to avoid MSVC warnings about conflicting defines.
cmake: Remove -D NDEBUG from CFLAGS as well as CXXFLAGS This silences ~7 warnings on .c files in the LLVM build. llvm-svn: 209163
2014-05-20 05:13:41 +08:00
foreach (flags_var_to_scrub
CMAKE_CXX_FLAGS_RELEASE
CMAKE_CXX_FLAGS_RELWITHDEBINFO
CMAKE_CXX_FLAGS_MINSIZEREL
CMAKE_C_FLAGS_RELEASE
CMAKE_C_FLAGS_RELWITHDEBINFO
CMAKE_C_FLAGS_MINSIZEREL)
string (REGEX REPLACE "(^| )[/-]D *NDEBUG($| )" " "
"${flags_var_to_scrub}" "${${flags_var_to_scrub}}")
endforeach()
Changes for building Clang and others using LLVM as an external library. Installs tblgen (required by Clang). Translates handling of user settings and platform-dependant options to its own file, where it can included by another project. Installs the .cmake files required by projects like Clang. llvm-svn: 124816
2011-02-04 04:57:36 +08:00
endif()
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 23:22:48 +08:00
if(LLVM_ENABLE_EXPENSIVE_CHECKS)
add_definitions(-DEXPENSIVE_CHECKS)
Build fix: Turn off _GLIBCXX_DEBUG based on a compile check Summary: Enabling _GLIBCXX_DEBUG (implied by LLVM_ENABLE_EXPENSIVE_CHECKS) causes std::min_element (and presumably others) to no longer be constexpr, which in turn causes the build to fail. This seems like a bug in the GCC STL. This change works around it. Change-Id: I5fc471caa9c4de3ef4e87aeeac8df1b960e8e72c Reviewers: tstellar, hans, serge-sans-paille Differential Revision: https://reviews.llvm.org/D75199
2020-02-27 02:47:14 +08:00
# In some libstdc++ versions, std::min_element is not constexpr when
# _GLIBCXX_DEBUG is enabled.
CHECK_CXX_SOURCE_COMPILES("
#define _GLIBCXX_DEBUG
#include <algorithm>
int main(int argc, char** argv) {
static constexpr int data[] = {0, 1};
constexpr const int* min_elt = std::min_element(&data[0], &data[2]);
return 0;
}" CXX_SUPPORTS_GLIBCXX_DEBUG)
if(CXX_SUPPORTS_GLIBCXX_DEBUG)
add_definitions(-D_GLIBCXX_DEBUG)
else()
add_definitions(-D_GLIBCXX_ASSERTIONS)
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 23:22:48 +08:00
endif()
[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 17:13:34 +08:00
[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-19 00:51:45 +08:00
if (LLVM_ENABLE_STRICT_FIXED_SIZE_VECTORS)
add_definitions(-DSTRICT_FIXED_SIZE_VECTORS)
[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 17:13:34 +08:00
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 23:22:48 +08:00
[ADT][CMake][AutoConf] Fail-fast iterators for DenseMap Summary: This patch is an attempt at making `DenseMapIterator`s "fail-fast". Fail-fast iterators that have been invalidated due to insertion into the host `DenseMap` deterministically trip an assert (in debug mode) on access, instead of non-deterministically hitting memory corruption issues. Enabling fail-fast iterators breaks the LLVM C++ ABI, so they are predicated on `LLVM_ENABLE_ABI_BREAKING_CHECKS`. `LLVM_ENABLE_ABI_BREAKING_CHECKS` by default flips with `LLVM_ENABLE_ASSERTS`, but can be clamped to ON or OFF using the CMake / autoconf build system. Reviewers: chandlerc, dexonsmith, rnk, zturner Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D8351 llvm-svn: 233310
2015-03-27 03:25:01 +08:00
string(TOUPPER "${LLVM_ABI_BREAKING_CHECKS}" uppercase_LLVM_ABI_BREAKING_CHECKS)
if( uppercase_LLVM_ABI_BREAKING_CHECKS STREQUAL "WITH_ASSERTS" )
if( LLVM_ENABLE_ASSERTIONS )
set( LLVM_ENABLE_ABI_BREAKING_CHECKS 1 )
endif()
elseif( uppercase_LLVM_ABI_BREAKING_CHECKS STREQUAL "FORCE_ON" )
set( LLVM_ENABLE_ABI_BREAKING_CHECKS 1 )
elseif( uppercase_LLVM_ABI_BREAKING_CHECKS STREQUAL "FORCE_OFF" )
# We don't need to do anything special to turn off ABI breaking checks.
Allow the CMake option 'LLVM_ABI_BREAKING_CHECKS' to be undefined. When building libc++abi in a standalone configuration the CMake option 'LLVM_ABI_BREAKING_CHECKS` will not be defined. llvm-svn: 237204
2015-05-13 06:49:18 +08:00
elseif( NOT DEFINED LLVM_ABI_BREAKING_CHECKS )
# Treat LLVM_ABI_BREAKING_CHECKS like "FORCE_OFF" when it has not been
# defined.
[ADT][CMake][AutoConf] Fail-fast iterators for DenseMap Summary: This patch is an attempt at making `DenseMapIterator`s "fail-fast". Fail-fast iterators that have been invalidated due to insertion into the host `DenseMap` deterministically trip an assert (in debug mode) on access, instead of non-deterministically hitting memory corruption issues. Enabling fail-fast iterators breaks the LLVM C++ ABI, so they are predicated on `LLVM_ENABLE_ABI_BREAKING_CHECKS`. `LLVM_ENABLE_ABI_BREAKING_CHECKS` by default flips with `LLVM_ENABLE_ASSERTS`, but can be clamped to ON or OFF using the CMake / autoconf build system. Reviewers: chandlerc, dexonsmith, rnk, zturner Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D8351 llvm-svn: 233310
2015-03-27 03:25:01 +08:00
else()
message(FATAL_ERROR "Unknown value for LLVM_ABI_BREAKING_CHECKS: \"${LLVM_ABI_BREAKING_CHECKS}\"!")
endif()
[cmake] Enable reverse iteration by default through build macro Summary: Reverse iteration can be turned on, by default, by setting -DLLVM_REVERSE_ITERATION:BOOL=ON during cmake. With this enabled, we can uncover lots of cases of non-determinism in codegen by simply running our tests (without any other change). We can then setup a buildbot which will have this turned on by default. Initially, a lot of unit tests will fail in this configuration. Once we start fixing non-determinism issues, we can gradually make this a blocker for patches. Reviewers: davide, dblaikie, mehdi_amini, dberlin Reviewed By: dblaikie Subscribers: probinson, mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D33908 llvm-svn: 304757
2017-06-06 08:36:09 +08:00
if( LLVM_REVERSE_ITERATION )
set( LLVM_ENABLE_REVERSE_ITERATION 1 )
endif()
Changes for building Clang and others using LLVM as an external library. Installs tblgen (required by Clang). Translates handling of user settings and platform-dependant options to its own file, where it can included by another project. Installs the .cmake files required by projects like Clang. llvm-svn: 124816
2011-02-04 04:57:36 +08:00
if(WIN32)
EXPORTED_SYMBOL_FILE support for cmake The cmake build didn't support EXPORTED_SYMBOL_FILE. Instead, it had a Windows-only implementation in tools/lto/CMakeLists.txt, a linux-only implementation in tools/gold/CMakeLists.txt, and a darwin-only implementation in tools/clang/tools/libclang/CMakeLists.txt. This attempts to consolidate these one-offs into a single place. Clients can now just set LLVM_EXPORTED_SYMBOL_FILE and things (hopefully) Just Work, like in the make build. llvm-svn: 198136
2013-12-29 07:31:44 +08:00
set(LLVM_HAVE_LINK_VERSION_SCRIPT 0)
Changes for building Clang and others using LLVM as an external library. Installs tblgen (required by Clang). Translates handling of user settings and platform-dependant options to its own file, where it can included by another project. Installs the .cmake files required by projects like Clang. llvm-svn: 124816
2011-02-04 04:57:36 +08:00
if(CYGWIN)
set(LLVM_ON_WIN32 0)
set(LLVM_ON_UNIX 1)
else(CYGWIN)
set(LLVM_ON_WIN32 1)
set(LLVM_ON_UNIX 0)
endif(CYGWIN)
else(WIN32)
[Support] Support building LLVM for Fuchsia These are necessary changes to support building LLVM for Fuchsia. While these are not sufficient to run on Fuchsia, they are still useful when cross-compiling LLVM libraries and runtimes for Fuchsia. Differential Revision: https://reviews.llvm.org/D46345 llvm-svn: 331423
2018-05-03 09:38:49 +08:00
if(FUCHSIA OR UNIX)
Changes for building Clang and others using LLVM as an external library. Installs tblgen (required by Clang). Translates handling of user settings and platform-dependant options to its own file, where it can included by another project. Installs the .cmake files required by projects like Clang. llvm-svn: 124816
2011-02-04 04:57:36 +08:00
set(LLVM_ON_WIN32 0)
set(LLVM_ON_UNIX 1)
Add AIX support to Path.inc, Host.h, and CMake. Patch by Andrew Paprocki! Differential Revision: https://reviews.llvm.org/D18359 llvm-svn: 276045
2016-07-20 06:46:39 +08:00
if(APPLE OR ${CMAKE_SYSTEM_NAME} MATCHES "AIX")
EXPORTED_SYMBOL_FILE support for cmake The cmake build didn't support EXPORTED_SYMBOL_FILE. Instead, it had a Windows-only implementation in tools/lto/CMakeLists.txt, a linux-only implementation in tools/gold/CMakeLists.txt, and a darwin-only implementation in tools/clang/tools/libclang/CMakeLists.txt. This attempts to consolidate these one-offs into a single place. Clients can now just set LLVM_EXPORTED_SYMBOL_FILE and things (hopefully) Just Work, like in the make build. llvm-svn: 198136
2013-12-29 07:31:44 +08:00
set(LLVM_HAVE_LINK_VERSION_SCRIPT 0)
Add AIX support to Path.inc, Host.h, and CMake. Patch by Andrew Paprocki! Differential Revision: https://reviews.llvm.org/D18359 llvm-svn: 276045
2016-07-20 06:46:39 +08:00
else()
EXPORTED_SYMBOL_FILE support for cmake The cmake build didn't support EXPORTED_SYMBOL_FILE. Instead, it had a Windows-only implementation in tools/lto/CMakeLists.txt, a linux-only implementation in tools/gold/CMakeLists.txt, and a darwin-only implementation in tools/clang/tools/libclang/CMakeLists.txt. This attempts to consolidate these one-offs into a single place. Clients can now just set LLVM_EXPORTED_SYMBOL_FILE and things (hopefully) Just Work, like in the make build. llvm-svn: 198136
2013-12-29 07:31:44 +08:00
set(LLVM_HAVE_LINK_VERSION_SCRIPT 1)
Add AIX support to Path.inc, Host.h, and CMake. Patch by Andrew Paprocki! Differential Revision: https://reviews.llvm.org/D18359 llvm-svn: 276045
2016-07-20 06:46:39 +08:00
endif()
[Support] Support building LLVM for Fuchsia These are necessary changes to support building LLVM for Fuchsia. While these are not sufficient to run on Fuchsia, they are still useful when cross-compiling LLVM libraries and runtimes for Fuchsia. Differential Revision: https://reviews.llvm.org/D46345 llvm-svn: 331423
2018-05-03 09:38:49 +08:00
else(FUCHSIA OR UNIX)
Changes for building Clang and others using LLVM as an external library. Installs tblgen (required by Clang). Translates handling of user settings and platform-dependant options to its own file, where it can included by another project. Installs the .cmake files required by projects like Clang. llvm-svn: 124816
2011-02-04 04:57:36 +08:00
MESSAGE(SEND_ERROR "Unable to determine platform")
[Support] Support building LLVM for Fuchsia These are necessary changes to support building LLVM for Fuchsia. While these are not sufficient to run on Fuchsia, they are still useful when cross-compiling LLVM libraries and runtimes for Fuchsia. Differential Revision: https://reviews.llvm.org/D46345 llvm-svn: 331423
2018-05-03 09:38:49 +08:00
endif(FUCHSIA OR UNIX)
Changes for building Clang and others using LLVM as an external library. Installs tblgen (required by Clang). Translates handling of user settings and platform-dependant options to its own file, where it can included by another project. Installs the .cmake files required by projects like Clang. llvm-svn: 124816
2011-02-04 04:57:36 +08:00
endif(WIN32)
CMake: Provide LLVM_PLUGIN_EXT definition This is needed to support the addition of tests for clang loadable plugins. In clang, plugins are built as modules (bundles on OS X) rather than dynamic libraries (dylib) so the build system needs to inform lit of the actual file extension in use, typically '.so' on Unix and '.dll' on Windows. (LLVM itself should probably switch to this scheme to fix PR14903 once and for all.) No change in build output or functionality intended. llvm-svn: 198746
2014-01-08 19:10:24 +08:00
set(EXEEXT ${CMAKE_EXECUTABLE_SUFFIX})
set(LTDL_SHLIB_EXT ${CMAKE_SHARED_LIBRARY_SUFFIX})
[CMake] LLVM_PLUGIN_EXT: Use CMAKE_SHARED_LIBRARY_SUFFIX rather than CMAKE_SHARED_MODULE_SUFFIX in llvm tree. FIXME: llvm/test may be aware of LLVM_PLUGIN_EXT, like as clang/test does. FIXME: CMAKE_*_SUFFIX may be set in HandleLLVMOptions if those variables could be writable, rather than to set one as target properties. llvm-svn: 201316
2014-02-13 19:19:00 +08:00
# We use *.dylib rather than *.so on darwin.
set(LLVM_PLUGIN_EXT ${CMAKE_SHARED_LIBRARY_SUFFIX})
CMake: Provide LLVM_PLUGIN_EXT definition This is needed to support the addition of tests for clang loadable plugins. In clang, plugins are built as modules (bundles on OS X) rather than dynamic libraries (dylib) so the build system needs to inform lit of the actual file extension in use, typically '.so' on Unix and '.dll' on Windows. (LLVM itself should probably switch to this scheme to fix PR14903 once and for all.) No change in build output or functionality intended. llvm-svn: 198746
2014-01-08 19:10:24 +08:00
[CMake] llvm_add_library(MODULE) may use CMAKE_MODULE_LINKER_FLAGS instead of target property LINK_FLAGS. I mis-dropped Darwin's link flags (in clang side) since r201073. llvm-svn: 201317
2014-02-13 19:19:11 +08:00
if(APPLE)
[CMake] Error when LTO and lld are enabled on Darwin lld on Darwin does not currently support LTO. Differential Revision: https://reviews.llvm.org/D26715 llvm-svn: 287256
2016-11-18 04:22:49 +08:00
if(LLVM_ENABLE_LLD AND LLVM_ENABLE_LTO)
message(FATAL_ERROR "lld does not support LTO on Darwin")
endif()
[CMake] llvm_add_library(MODULE) may use CMAKE_MODULE_LINKER_FLAGS instead of target property LINK_FLAGS. I mis-dropped Darwin's link flags (in clang side) since r201073. llvm-svn: 201317
2014-02-13 19:19:11 +08:00
# Darwin-specific linker flags for loadable modules.
set(CMAKE_MODULE_LINKER_FLAGS "${CMAKE_MODULE_LINKER_FLAGS} -Wl,-flat_namespace -Wl,-undefined -Wl,suppress")
endif()
[CMake] Fix LLVM build non-determinism on RHEL On RHEL, the OS tooling (ar, ranlib) is not deterministic by default. Therefore, we cannot get bit-for-bit identical builds. The goal of this patch is that it adds the flags required to force determinism. Differential Revision: https://reviews.llvm.org/D64817
2019-11-22 13:06:33 +08:00
if(${CMAKE_SYSTEM_NAME} MATCHES "Linux")
# RHEL7 has ar and ranlib being non-deterministic by default. The D flag forces determinism,
[NFC] Remove ar/ranlib test noise during cmake step At least on RHEL, ar outputs on stderr a message similar to .../bin/ar: creating t.a Which creates noise during the cmake step. Get rid of it.
2020-02-20 18:22:35 +08:00
# however only GNU version of ar and ranlib (2.27) have this option.
[CMake] Fix LLVM build non-determinism on RHEL On RHEL, the OS tooling (ar, ranlib) is not deterministic by default. Therefore, we cannot get bit-for-bit identical builds. The goal of this patch is that it adds the flags required to force determinism. Differential Revision: https://reviews.llvm.org/D64817
2019-11-22 13:06:33 +08:00
# RHEL DTS7 is also affected by this, which uses GNU binutils 2.28
execute_process(COMMAND ${CMAKE_AR} rD t.a
[NFC] Remove ar/ranlib test noise during cmake step At least on RHEL, ar outputs on stderr a message similar to .../bin/ar: creating t.a Which creates noise during the cmake step. Get rid of it.
2020-02-20 18:22:35 +08:00
WORKING_DIRECTORY ${CMAKE_BINARY_DIR}
RESULT_VARIABLE AR_RESULT
OUTPUT_QUIET
ERROR_QUIET
)
[CMake] Fix LLVM build non-determinism on RHEL On RHEL, the OS tooling (ar, ranlib) is not deterministic by default. Therefore, we cannot get bit-for-bit identical builds. The goal of this patch is that it adds the flags required to force determinism. Differential Revision: https://reviews.llvm.org/D64817
2019-11-22 13:06:33 +08:00
if(${AR_RESULT} EQUAL 0)
execute_process(COMMAND ${CMAKE_RANLIB} -D t.a
[NFC] Remove ar/ranlib test noise during cmake step At least on RHEL, ar outputs on stderr a message similar to .../bin/ar: creating t.a Which creates noise during the cmake step. Get rid of it.
2020-02-20 18:22:35 +08:00
WORKING_DIRECTORY ${CMAKE_BINARY_DIR}
RESULT_VARIABLE RANLIB_RESULT
OUTPUT_QUIET
ERROR_QUIET
)
[CMake] Fix LLVM build non-determinism on RHEL On RHEL, the OS tooling (ar, ranlib) is not deterministic by default. Therefore, we cannot get bit-for-bit identical builds. The goal of this patch is that it adds the flags required to force determinism. Differential Revision: https://reviews.llvm.org/D64817
2019-11-22 13:06:33 +08:00
if(${RANLIB_RESULT} EQUAL 0)
set(CMAKE_C_ARCHIVE_CREATE "<CMAKE_AR> Dqc <TARGET> <LINK_FLAGS> <OBJECTS>")
set(CMAKE_C_ARCHIVE_APPEND "<CMAKE_AR> Dq <TARGET> <LINK_FLAGS> <OBJECTS>")
set(CMAKE_C_ARCHIVE_FINISH "<CMAKE_RANLIB> -D <TARGET>")
set(CMAKE_CXX_ARCHIVE_CREATE "<CMAKE_AR> Dqc <TARGET> <LINK_FLAGS> <OBJECTS>")
set(CMAKE_CXX_ARCHIVE_APPEND "<CMAKE_AR> Dq <TARGET> <LINK_FLAGS> <OBJECTS>")
set(CMAKE_CXX_ARCHIVE_FINISH "<CMAKE_RANLIB> -D <TARGET>")
endif()
file(REMOVE ${CMAKE_BINARY_DIR}/t.a)
endif()
endif()
[AIX][CMake] Changes for building on AIX with XL and GCC Summary: In support of IBM's efforts to produce a viable C and C++ LLVM compiler for AIX (ref: RFC at http://lists.llvm.org/pipermail/llvm-dev/2019-February/130175.html), this patch adds customizations to the CMake files in order to properly invoke the host toolchain for the build on AIX. Additional changes to enable a successful build will follow. Patch by Xing Xue Reviewers: hubert.reinterpretcast, jasonliu, sfertile Reviewed by: hubert.reinterpretcast Differential Revision: https://reviews.llvm.org/D58250 llvm-svn: 356104
2019-03-14 05:50:25 +08:00
if(${CMAKE_SYSTEM_NAME} MATCHES "AIX")
# -fPIC does not enable the large code model for GCC on AIX but does for XL.
if(CMAKE_CXX_COMPILER_ID STREQUAL "GNU")
append("-mcmodel=large" CMAKE_CXX_FLAGS CMAKE_C_FLAGS)
elseif(CMAKE_CXX_COMPILER_ID MATCHES "XL")
# XL generates a small number of relocations not of the large model, -bbigtoc is needed.
append("-Wl,-bbigtoc"
CMAKE_EXE_LINKER_FLAGS CMAKE_MODULE_LINKER_FLAGS CMAKE_SHARED_LINKER_FLAGS)
[CMake][AIX] Add `-bcdtors:mbr` option when building with IBM XL Summary: The `-bcdtors:mbr` option causes processing for constructors and destructors to omit otherwise-unreferenced members of static libraries, matching the processing done on Linux, where `--whole-archive` is not the default. Applying this option is desirable for reducing the footprint of an installation. Reviewed By: daltenty Differential Revision: https://reviews.llvm.org/D79749
2020-05-16 05:15:04 +08:00
# The default behaviour on AIX processes dynamic initialization of non-local variables with
# static storage duration even for archive members that are otherwise unreferenced.
# Since `--whole-archive` is not used by the LLVM build to keep such initializations for Linux,
# we can limit the processing for archive members to only those that are otherwise referenced.
append("-bcdtors:mbr"
CMAKE_EXE_LINKER_FLAGS CMAKE_MODULE_LINKER_FLAGS CMAKE_SHARED_LINKER_FLAGS)
[AIX][CMake] Changes for building on AIX with XL and GCC Summary: In support of IBM's efforts to produce a viable C and C++ LLVM compiler for AIX (ref: RFC at http://lists.llvm.org/pipermail/llvm-dev/2019-February/130175.html), this patch adds customizations to the CMake files in order to properly invoke the host toolchain for the build on AIX. Additional changes to enable a successful build will follow. Patch by Xing Xue Reviewers: hubert.reinterpretcast, jasonliu, sfertile Reviewed by: hubert.reinterpretcast Differential Revision: https://reviews.llvm.org/D58250 llvm-svn: 356104
2019-03-14 05:50:25 +08:00
endif()
endif()
Pass -Wl,-z,defs when building shared libraries, but not with the sanitizers. llvm-svn: 226828
2015-01-22 22:06:51 +08:00
# Pass -Wl,-z,defs. This makes sure all symbols are defined. Otherwise a DSO
# build might work on ELF but fail on MachO/COFF.
[CMake] Add -z defs on Solaris Like other ELF targets, shared objects should be linked with -z defs on Solaris. Tested on x86_64-pc-solaris2.11 and sparcv9-sun-solaris2.11. Differential Revision: https://reviews.llvm.org/D64484 llvm-svn: 366821
2019-07-24 00:27:34 +08:00
if(NOT (${CMAKE_SYSTEM_NAME} MATCHES "Darwin|FreeBSD|OpenBSD|DragonFly|AIX|SunOS" OR
[AIX][CMake] Changes for building on AIX with XL and GCC Summary: In support of IBM's efforts to produce a viable C and C++ LLVM compiler for AIX (ref: RFC at http://lists.llvm.org/pipermail/llvm-dev/2019-February/130175.html), this patch adds customizations to the CMake files in order to properly invoke the host toolchain for the build on AIX. Additional changes to enable a successful build will follow. Patch by Xing Xue Reviewers: hubert.reinterpretcast, jasonliu, sfertile Reviewed by: hubert.reinterpretcast Differential Revision: https://reviews.llvm.org/D58250 llvm-svn: 356104
2019-03-14 05:50:25 +08:00
WIN32 OR CYGWIN) AND
Don't use -z,defs on FreeBSD. Looks like environ is defined only in the main binary. llvm-svn: 226862
2015-01-23 04:57:30 +08:00
NOT LLVM_USE_SANITIZER)
Pass -Wl,-z,defs when building shared libraries, but not with the sanitizers. llvm-svn: 226828
2015-01-22 22:06:51 +08:00
set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -Wl,-z,defs")
endif()
[cmake] Pass -Wl,-z,nodelete on Linux to prevent unloading Prevent unloading shared libraries on Linux when dlclose() is called. This is necessary since command-line option parsing API relies on registering the global option instances in the option parser instance which can be loaded in a different shared library. Given that we can't reliably remove those options when a library is unloaded, the parser ends up containing dangling references. Since glibc has relatively complex library unloading rules, some of the LLVM libraries can be unloaded while others (including the Support library) stay loaded causing quite a mayhem. To reliably prevent that, just forbid unloading all libraries -- it's a very bad idea anyway. While the issue arguably happens only with BUILD_SHARED_LIBS, it may affect any library reusing llvm::cl interface. Based on patch provided Ross Hayward on https://bugs.gentoo.org/617154. Previously hit by Fedora back in Feb 2016: https://lists.freedesktop.org/archives/mesa-dev/2016-February/107242.html Differential Revision: https://reviews.llvm.org/D40459 llvm-svn: 319105
2017-11-28 06:23:09 +08:00
# Pass -Wl,-z,nodelete. This makes sure our shared libraries are not unloaded
# by dlclose(). We need that since the CLI API relies on cross-references
# between global objects which became horribly broken when one of the libraries
# is unloaded.
if(${CMAKE_SYSTEM_NAME} MATCHES "Linux")
set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -Wl,-z,nodelete")
[cmake] Prevent LLVMgold.so from being unloaded on Linux Extend the fix from D40459 to also apply to modules such as the LLVM gold plugin. This is needed because current binutils master (and future binutils 2.32) calls dlclose() on bfd plugins as part of a recent fix for https://sourceware.org/bugzilla/show_bug.cgi?id=23460. Patch by Evangelos Foutras! Differential Revision: https://reviews.llvm.org/D50416 llvm-svn: 339883
2018-08-16 23:12:12 +08:00
set(CMAKE_MODULE_LINKER_FLAGS "${CMAKE_MODULE_LINKER_FLAGS} -Wl,-z,nodelete")
[cmake] Pass -Wl,-z,nodelete on Linux to prevent unloading Prevent unloading shared libraries on Linux when dlclose() is called. This is necessary since command-line option parsing API relies on registering the global option instances in the option parser instance which can be loaded in a different shared library. Given that we can't reliably remove those options when a library is unloaded, the parser ends up containing dangling references. Since glibc has relatively complex library unloading rules, some of the LLVM libraries can be unloaded while others (including the Support library) stay loaded causing quite a mayhem. To reliably prevent that, just forbid unloading all libraries -- it's a very bad idea anyway. While the issue arguably happens only with BUILD_SHARED_LIBS, it may affect any library reusing llvm::cl interface. Based on patch provided Ross Hayward on https://bugs.gentoo.org/617154. Previously hit by Fedora back in Feb 2016: https://lists.freedesktop.org/archives/mesa-dev/2016-February/107242.html Differential Revision: https://reviews.llvm.org/D40459 llvm-svn: 319105
2017-11-28 06:23:09 +08:00
endif()
Pass -Wl,-z,defs when building shared libraries, but not with the sanitizers. llvm-svn: 226828
2015-01-22 22:06:51 +08:00
Don't use add_llvm_definitions for adding warning flags. It makes it too hard to have them appear in the right order. Instead append all warnings explicitly to the language flags. This was already the case for many warnings. Fixes the issue of -Wno-maybe-uninitialized not being effective because -Wall was being placed after it rather than before. llvm-svn: 177866
2013-03-25 21:25:34 +08:00
function(append value)
foreach(variable ${ARGN})
Simplify CMake rules in HandleLLVMOptions module. Summary: No functionality change. Reviewers: Bigcheese Reviewed By: Bigcheese CC: llvm-commits Differential Revision: http://llvm-reviews.chandlerc.com/D535 llvm-svn: 176973
2013-03-14 04:50:23 +08:00
set(${variable} "${${variable}} ${value}" PARENT_SCOPE)
Don't use add_llvm_definitions for adding warning flags. It makes it too hard to have them appear in the right order. Instead append all warnings explicitly to the language flags. This was already the case for many warnings. Fixes the issue of -Wno-maybe-uninitialized not being effective because -Wall was being placed after it rather than before. llvm-svn: 177866
2013-03-25 21:25:34 +08:00
endforeach(variable)
endfunction()
function(append_if condition value)
if (${condition})
foreach(variable ${ARGN})
set(${variable} "${${variable}} ${value}" PARENT_SCOPE)
endforeach(variable)
Simplify CMake rules in HandleLLVMOptions module. Summary: No functionality change. Reviewers: Bigcheese Reviewed By: Bigcheese CC: llvm-commits Differential Revision: http://llvm-reviews.chandlerc.com/D535 llvm-svn: 176973
2013-03-14 04:50:23 +08:00
endif()
endfunction()
CMake: fix compiler feature detection add_flag_if_supported() and add_flag_or_print_warning() were effectively no-ops, just returning the value of the first result (usually '-fno-omit-frame-pointer') for all subsequent checks for different flags. Due to the way CMake caches feature detection results, we need to provide symbolic variable names which will persist the cached results. This commit fixes feature detection using these two macros. The feature checks now run and get stored correctly, and the correct output can be observed in configure logs: -- Performing Test C_SUPPORTS_FPIC -- Performing Test C_SUPPORTS_FPIC - Success -- Performing Test CXX_SUPPORTS_FPIC -- Performing Test CXX_SUPPORTS_FPIC - Success llvm-svn: 212586
2014-07-09 11:38:19 +08:00
macro(add_flag_if_supported flag name)
check_c_compiler_flag("-Werror ${flag}" "C_SUPPORTS_${name}")
append_if("C_SUPPORTS_${name}" "${flag}" CMAKE_C_FLAGS)
check_cxx_compiler_flag("-Werror ${flag}" "CXX_SUPPORTS_${name}")
append_if("CXX_SUPPORTS_${name}" "${flag}" CMAKE_CXX_FLAGS)
Add CMake option LLVM_USE_SANITIZER={Address,Memory,MemoryWithOrigins} to simplify bootstrap of LLVM/Clang under ASan/MSan llvm-svn: 177992
2013-03-26 15:49:46 +08:00
endmacro()
CMake: fix compiler feature detection add_flag_if_supported() and add_flag_or_print_warning() were effectively no-ops, just returning the value of the first result (usually '-fno-omit-frame-pointer') for all subsequent checks for different flags. Due to the way CMake caches feature detection results, we need to provide symbolic variable names which will persist the cached results. This commit fixes feature detection using these two macros. The feature checks now run and get stored correctly, and the correct output can be observed in configure logs: -- Performing Test C_SUPPORTS_FPIC -- Performing Test C_SUPPORTS_FPIC - Success -- Performing Test CXX_SUPPORTS_FPIC -- Performing Test CXX_SUPPORTS_FPIC - Success llvm-svn: 212586
2014-07-09 11:38:19 +08:00
function(add_flag_or_print_warning flag name)
check_c_compiler_flag("-Werror ${flag}" "C_SUPPORTS_${name}")
check_cxx_compiler_flag("-Werror ${flag}" "CXX_SUPPORTS_${name}")
Fix CMake warning CMP0054: don't quote a variable name that is intended to be expanded; future versions of cmake may not expand the variable in this case. llvm-svn: 218543
2014-09-27 05:35:48 +08:00
if (C_SUPPORTS_${name} AND CXX_SUPPORTS_${name})
CMake: fix compiler feature detection add_flag_if_supported() and add_flag_or_print_warning() were effectively no-ops, just returning the value of the first result (usually '-fno-omit-frame-pointer') for all subsequent checks for different flags. Due to the way CMake caches feature detection results, we need to provide symbolic variable names which will persist the cached results. This commit fixes feature detection using these two macros. The feature checks now run and get stored correctly, and the correct output can be observed in configure logs: -- Performing Test C_SUPPORTS_FPIC -- Performing Test C_SUPPORTS_FPIC - Success -- Performing Test CXX_SUPPORTS_FPIC -- Performing Test CXX_SUPPORTS_FPIC - Success llvm-svn: 212586
2014-07-09 11:38:19 +08:00
message(STATUS "Building with ${flag}")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${flag}" PARENT_SCOPE)
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${flag}" PARENT_SCOPE)
Use a specified list of languages in cmake project() command. This allows asm files and Cxx files to be compiled with different flags rather than treating them identically. LLVM itself has no asm files other than tests, but this setting is inherited by the compiler-rt project (unless compiled standalone), which does have asm files. Differential Revision: http://reviews.llvm.org/D10707 llvm-svn: 243419
2015-07-28 22:43:53 +08:00
set(CMAKE_ASM_FLAGS "${CMAKE_ASM_FLAGS} ${flag}" PARENT_SCOPE)
CMake: fix compiler feature detection add_flag_if_supported() and add_flag_or_print_warning() were effectively no-ops, just returning the value of the first result (usually '-fno-omit-frame-pointer') for all subsequent checks for different flags. Due to the way CMake caches feature detection results, we need to provide symbolic variable names which will persist the cached results. This commit fixes feature detection using these two macros. The feature checks now run and get stored correctly, and the correct output can be observed in configure logs: -- Performing Test C_SUPPORTS_FPIC -- Performing Test C_SUPPORTS_FPIC - Success -- Performing Test CXX_SUPPORTS_FPIC -- Performing Test CXX_SUPPORTS_FPIC - Success llvm-svn: 212586
2014-07-09 11:38:19 +08:00
else()
message(WARNING "${flag} is not supported.")
endif()
endfunction()
Add a LLVM_USE_LINKER that defines the linker to use when building LLVM Summary: This string parameter is passed to -fuse-ld when linking. It can be an absolute path to your custom linker, otherwise clang will look for `ld.{name}`. Reviewers: davide, tejohnson, pcc Subscribers: llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D28738 llvm-svn: 292047
2017-01-15 11:21:30 +08:00
if( LLVM_ENABLE_LLD )
Fix whitespace mismatches. NFCI. Tabs are not our friends. llvm-svn: 360248
2019-05-08 21:02:32 +08:00
if ( LLVM_USE_LINKER )
message(FATAL_ERROR "LLVM_ENABLE_LLD and LLVM_USE_LINKER can't be set at the same time")
endif()
set(LLVM_USE_LINKER "lld")
Add a LLVM_USE_LINKER that defines the linker to use when building LLVM Summary: This string parameter is passed to -fuse-ld when linking. It can be an absolute path to your custom linker, otherwise clang will look for `ld.{name}`. Reviewers: davide, tejohnson, pcc Subscribers: llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D28738 llvm-svn: 292047
2017-01-15 11:21:30 +08:00
endif()
if( LLVM_USE_LINKER )
Fix -fuse-ld feature detection error. check_cxx_compiler_flag doesn't seem to try to link a program, so the existing code doesn't correctly detect the availability of a given linker. This patch uses check_cxx_source_compiles instead. I confirmed that cmake now reports this error Host compiler does not support '-fuse-ld=foo' for -DLLVM_USE_LINKER=foo. Differential Revision: https://reviews.llvm.org/D39274 llvm-svn: 316958
2017-10-31 05:19:54 +08:00
set(OLD_CMAKE_REQUIRED_FLAGS ${CMAKE_REQUIRED_FLAGS})
set(CMAKE_REQUIRED_FLAGS "${CMAKE_REQUIRED_FLAGS} -fuse-ld=${LLVM_USE_LINKER}")
check_cxx_source_compiles("int main() { return 0; }" CXX_SUPPORTS_CUSTOM_LINKER)
Add a LLVM_USE_LINKER that defines the linker to use when building LLVM Summary: This string parameter is passed to -fuse-ld when linking. It can be an absolute path to your custom linker, otherwise clang will look for `ld.{name}`. Reviewers: davide, tejohnson, pcc Subscribers: llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D28738 llvm-svn: 292047
2017-01-15 11:21:30 +08:00
if ( NOT CXX_SUPPORTS_CUSTOM_LINKER )
Fix whitespace mismatches. NFCI. Tabs are not our friends. llvm-svn: 360248
2019-05-08 21:02:32 +08:00
message(FATAL_ERROR "Host compiler does not support '-fuse-ld=${LLVM_USE_LINKER}'")
Add a LLVM_USE_LINKER that defines the linker to use when building LLVM Summary: This string parameter is passed to -fuse-ld when linking. It can be an absolute path to your custom linker, otherwise clang will look for `ld.{name}`. Reviewers: davide, tejohnson, pcc Subscribers: llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D28738 llvm-svn: 292047
2017-01-15 11:21:30 +08:00
endif()
Fix -fuse-ld feature detection error. check_cxx_compiler_flag doesn't seem to try to link a program, so the existing code doesn't correctly detect the availability of a given linker. This patch uses check_cxx_source_compiles instead. I confirmed that cmake now reports this error Host compiler does not support '-fuse-ld=foo' for -DLLVM_USE_LINKER=foo. Differential Revision: https://reviews.llvm.org/D39274 llvm-svn: 316958
2017-10-31 05:19:54 +08:00
set(CMAKE_REQUIRED_FLAGS ${OLD_CMAKE_REQUIRED_FLAGS})
Add a LLVM_USE_LINKER that defines the linker to use when building LLVM Summary: This string parameter is passed to -fuse-ld when linking. It can be an absolute path to your custom linker, otherwise clang will look for `ld.{name}`. Reviewers: davide, tejohnson, pcc Subscribers: llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D28738 llvm-svn: 292047
2017-01-15 11:21:30 +08:00
append("-fuse-ld=${LLVM_USE_LINKER}"
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 08:46:13 +08:00
CMAKE_EXE_LINKER_FLAGS CMAKE_MODULE_LINKER_FLAGS CMAKE_SHARED_LINKER_FLAGS)
endif()
Changes for building Clang and others using LLVM as an external library. Installs tblgen (required by Clang). Translates handling of user settings and platform-dependant options to its own file, where it can included by another project. Installs the .cmake files required by projects like Clang. llvm-svn: 124816
2011-02-04 04:57:36 +08:00
if( LLVM_ENABLE_PIC )
if( XCODE )
# Xcode has -mdynamic-no-pic on by default, which overrides -fPIC. I don't
# know how to disable this, so just force ENABLE_PIC off for now.
message(WARNING "-fPIC not supported with Xcode.")
Tweak CMake build on Cygwin. llvm-svn: 146725
2011-12-16 14:21:08 +08:00
elseif( WIN32 OR CYGWIN)
Changes for building Clang and others using LLVM as an external library. Installs tblgen (required by Clang). Translates handling of user settings and platform-dependant options to its own file, where it can included by another project. Installs the .cmake files required by projects like Clang. llvm-svn: 124816
2011-02-04 04:57:36 +08:00
# On Windows all code is PIC. MinGW warns if -fPIC is used.
else()
CMake: fix compiler feature detection add_flag_if_supported() and add_flag_or_print_warning() were effectively no-ops, just returning the value of the first result (usually '-fno-omit-frame-pointer') for all subsequent checks for different flags. Due to the way CMake caches feature detection results, we need to provide symbolic variable names which will persist the cached results. This commit fixes feature detection using these two macros. The feature checks now run and get stored correctly, and the correct output can be observed in configure logs: -- Performing Test C_SUPPORTS_FPIC -- Performing Test C_SUPPORTS_FPIC - Success -- Performing Test CXX_SUPPORTS_FPIC -- Performing Test CXX_SUPPORTS_FPIC - Success llvm-svn: 212586
2014-07-09 11:38:19 +08:00
add_flag_or_print_warning("-fPIC" FPIC)
Changes for building Clang and others using LLVM as an external library. Installs tblgen (required by Clang). Translates handling of user settings and platform-dependant options to its own file, where it can included by another project. Installs the .cmake files required by projects like Clang. llvm-svn: 124816
2011-02-04 04:57:36 +08:00
endif()
[cmake] Disable a GCC optimization when building LLVM for MIPS GCC when compiling LLVM for MIPS can introduce a jump to an uninitialized value when shrink wrapping is enabled. As shrink wrapping is enabled in GCC at all optimization levels, it must be disabled. This bug exists for all versions of GCC since 4.9.2. This partially resolves PR37701 / GCC PR target/86069. Patch by Simon Dardis. Differential Revision: https://reviews.llvm.org/D48069 llvm-svn: 359376
2019-04-27 17:28:54 +08:00
# GCC for MIPS can miscompile LLVM due to PR37701.
if(CMAKE_COMPILER_IS_GNUCXX AND LLVM_NATIVE_ARCH STREQUAL "Mips" AND
NOT Uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG")
add_flag_or_print_warning("-fno-shrink-wrap" FNO_SHRINK_WRAP)
endif()
Changes for building Clang and others using LLVM as an external library. Installs tblgen (required by Clang). Translates handling of user settings and platform-dependant options to its own file, where it can included by another project. Installs the .cmake files required by projects like Clang. llvm-svn: 124816
2011-02-04 04:57:36 +08:00
endif()
[AIX][CMake] Changes for building on AIX with XL and GCC Summary: In support of IBM's efforts to produce a viable C and C++ LLVM compiler for AIX (ref: RFC at http://lists.llvm.org/pipermail/llvm-dev/2019-February/130175.html), this patch adds customizations to the CMake files in order to properly invoke the host toolchain for the build on AIX. Additional changes to enable a successful build will follow. Patch by Xing Xue Reviewers: hubert.reinterpretcast, jasonliu, sfertile Reviewed by: hubert.reinterpretcast Differential Revision: https://reviews.llvm.org/D58250 llvm-svn: 356104
2019-03-14 05:50:25 +08:00
if(NOT WIN32 AND NOT CYGWIN AND NOT (${CMAKE_SYSTEM_NAME} MATCHES "AIX" AND CMAKE_CXX_COMPILER_ID STREQUAL "GNU"))
[CMake] Support -fvisibility-inlines-hidden when LLVM_ENABLE_PIC=Off I'm unaware of any reasons why -fvisibility-inlines-hidden would depend on PIC, and since autoconf supports this flag without PIC, we should support it in CMake too. llvm-svn: 253517
2015-11-19 06:49:26 +08:00
# MinGW warns if -fvisibility-inlines-hidden is used.
[AIX][CMake] Changes for building on AIX with XL and GCC Summary: In support of IBM's efforts to produce a viable C and C++ LLVM compiler for AIX (ref: RFC at http://lists.llvm.org/pipermail/llvm-dev/2019-February/130175.html), this patch adds customizations to the CMake files in order to properly invoke the host toolchain for the build on AIX. Additional changes to enable a successful build will follow. Patch by Xing Xue Reviewers: hubert.reinterpretcast, jasonliu, sfertile Reviewed by: hubert.reinterpretcast Differential Revision: https://reviews.llvm.org/D58250 llvm-svn: 356104
2019-03-14 05:50:25 +08:00
# GCC on AIX warns if -fvisibility-inlines-hidden is used.
[CMake] Support -fvisibility-inlines-hidden when LLVM_ENABLE_PIC=Off I'm unaware of any reasons why -fvisibility-inlines-hidden would depend on PIC, and since autoconf supports this flag without PIC, we should support it in CMake too. llvm-svn: 253517
2015-11-19 06:49:26 +08:00
check_cxx_compiler_flag("-fvisibility-inlines-hidden" SUPPORTS_FVISIBILITY_INLINES_HIDDEN_FLAG)
append_if(SUPPORTS_FVISIBILITY_INLINES_HIDDEN_FLAG "-fvisibility-inlines-hidden" CMAKE_CXX_FLAGS)
endif()
[MinGW] Enable large file for mingw-w64 64-bit mingw doesn't define _FILE_OFFSET_BITS=64 by default. Differential Revision: https://reviews.llvm.org/D53569 llvm-svn: 345131
2018-10-24 20:22:12 +08:00
if(CMAKE_SIZEOF_VOID_P EQUAL 8 AND MINGW)
add_definitions( -D_FILE_OFFSET_BITS=64 )
endif()
Changes for building Clang and others using LLVM as an external library. Installs tblgen (required by Clang). Translates handling of user settings and platform-dependant options to its own file, where it can included by another project. Installs the .cmake files required by projects like Clang. llvm-svn: 124816
2011-02-04 04:57:36 +08:00
if( CMAKE_SIZEOF_VOID_P EQUAL 8 AND NOT WIN32 )
# TODO: support other platforms and toolchains.
if( LLVM_BUILD_32_BITS )
message(STATUS "Building 32 bits executables and libraries.")
LLVM_BUILD_32_BITS: Add -m32 with CMAKE_C*_FLAGS. [CMP0056] With CMP0056, try_compile() uses also CMAKE_EXE_LINKER_FLAG. It caused mismatch between CMAKE_CXX_FLAGS and CMAKE_EXE_LINKER_FLAGS, to fail to examine CXX_SUPPORTS_CXX11 with -m32. FYI, before this, try_compile() tries without -m32 regardless of LLVM_BUILD_32_BITS. llvm-svn: 271871
2016-06-06 13:54:55 +08:00
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -m32")
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -m32")
Fix how CMake appends -m32 to linker command-lines llvm-svn: 157337
2012-05-24 02:42:02 +08:00
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -m32")
set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -m32")
cmake: Pass the -m32 flag to modules if LLVM_BUILD_32_BITS is enabled This was previously only done for executables and shared libraries, but not for modules. As modules are essentially shared libraries (that need to be dlopened explicitly), threating them the same as shared libraries seems reasonable. This fixes the LLVM_BUILD_32_BITS build of Polly. Contributed by: Ondra Hosek <ondra.hosek@gmail.com> llvm-svn: 158195
2012-06-08 17:41:23 +08:00
set(CMAKE_MODULE_LINKER_FLAGS "${CMAKE_MODULE_LINKER_FLAGS} -m32")
CMake: Let LLVM_BUILD_32_BITS aware of large file. llvm-svn: 317402
2017-11-04 14:03:29 +08:00
# FIXME: CMAKE_SIZEOF_VOID_P is still 8
add_definitions(-D_LARGEFILE_SOURCE)
add_definitions(-D_FILE_OFFSET_BITS=64)
Changes for building Clang and others using LLVM as an external library. Installs tblgen (required by Clang). Translates handling of user settings and platform-dependant options to its own file, where it can included by another project. Installs the .cmake files required by projects like Clang. llvm-svn: 124816
2011-02-04 04:57:36 +08:00
endif( LLVM_BUILD_32_BITS )
endif( CMAKE_SIZEOF_VOID_P EQUAL 8 AND NOT WIN32 )
[LLVM][MIPS] Fix different definition of off_t in LLDB and LLVM. Reviewers: beanz Subscribers: jaydeep, bhushan, lldb-commits, slthakur, llvm-commits, krytarowski, emaste Differential Revision: https://reviews.llvm.org/D32125 llvm-svn: 301171
2017-04-24 18:36:46 +08:00
# If building on a GNU specific 32-bit system, make sure off_t is 64 bits
Disable 64bit file position on old 32 bit Androids. This is needed for building LLVM on Android with new NDK (newer than r15c) and API level < 24. Android C library (Bionic) didn't have support for 64 bit file position until Android N. Differential Revision: https://reviews.llvm.org/D37314 llvm-svn: 312389
2017-09-02 07:12:43 +08:00
# so that off_t can stored offset > 2GB.
# Android until version N (API 24) doesn't support it.
if (ANDROID AND (ANDROID_NATIVE_API_LEVEL LESS 24))
set(LLVM_FORCE_SMALLFILE_FOR_ANDROID TRUE)
endif()
if( CMAKE_SIZEOF_VOID_P EQUAL 4 AND NOT LLVM_FORCE_SMALLFILE_FOR_ANDROID)
CMake: Let LLVM_BUILD_32_BITS aware of large file. llvm-svn: 317402
2017-11-04 14:03:29 +08:00
# FIXME: It isn't handled in LLVM_BUILD_32_BITS.
[LLVM][MIPS] Fix different definition of off_t in LLDB and LLVM. Reviewers: beanz Subscribers: jaydeep, bhushan, lldb-commits, slthakur, llvm-commits, krytarowski, emaste Differential Revision: https://reviews.llvm.org/D32125 llvm-svn: 301171
2017-04-24 18:36:46 +08:00
add_definitions( -D_LARGEFILE_SOURCE )
add_definitions( -D_FILE_OFFSET_BITS=64 )
endif()
[CMake] Enable a bunch of Xcode build settings that correspond to warnings that are for the most part enabled by default either by Clang or -Wall. I personally build with these settings enabled all the time, and it is clearer to see the actual warning flags (e.g., -Wuninitialized) get passed by Xcode rather than seeing -Wno-uninitialized followed by -Wall (the latter canceling out the former) and figuring out what is going on. Xcode will ignore build settings it doesn't understand, so this will work on possibly older versions of Xcode that don't support all of these settings. llvm-svn: 203760
2014-03-13 14:37:28 +08:00
if( XCODE )
# For Xcode enable several build settings that correspond to
# many warnings that are on by default in Clang but are
# not enabled for historical reasons. For versions of Xcode
# that do not support these options they will simply
# be ignored.
set(CMAKE_XCODE_ATTRIBUTE_GCC_WARN_ABOUT_RETURN_TYPE "YES")
set(CMAKE_XCODE_ATTRIBUTE_GCC_WARN_ABOUT_MISSING_NEWLINE "YES")
set(CMAKE_XCODE_ATTRIBUTE_GCC_WARN_UNUSED_VALUE "YES")
set(CMAKE_XCODE_ATTRIBUTE_GCC_WARN_UNUSED_VARIABLE "YES")
set(CMAKE_XCODE_ATTRIBUTE_GCC_WARN_SIGN_COMPARE "YES")
set(CMAKE_XCODE_ATTRIBUTE_GCC_WARN_UNUSED_FUNCTION "YES")
set(CMAKE_XCODE_ATTRIBUTE_GCC_WARN_INITIALIZER_NOT_FULLY_BRACKETED "YES")
set(CMAKE_XCODE_ATTRIBUTE_GCC_WARN_HIDDEN_VIRTUAL_FUNCTIONS "YES")
set(CMAKE_XCODE_ATTRIBUTE_GCC_WARN_UNINITIALIZED_AUTOS "YES")
set(CMAKE_XCODE_ATTRIBUTE_CLANG_WARN_BOOL_CONVERSION "YES")
set(CMAKE_XCODE_ATTRIBUTE_CLANG_WARN_EMPTY_BODY "YES")
set(CMAKE_XCODE_ATTRIBUTE_CLANG_WARN_ENUM_CONVERSION "YES")
set(CMAKE_XCODE_ATTRIBUTE_CLANG_WARN_INT_CONVERSION "YES")
set(CMAKE_XCODE_ATTRIBUTE_CLANG_WARN_CONSTANT_CONVERSION "YES")
set(CMAKE_XCODE_ATTRIBUTE_GCC_WARN_NON_VIRTUAL_DESTRUCTOR "YES")
endif()
CMake: Prune redundant LLVM_COMPILER_JOBS from llvm/CMakeLists.txt. HandleLLVMOptions.cmake has it. llvm-svn: 155284
2012-04-21 22:50:56 +08:00
# On Win32 using MS tools, provide an option to set the number of parallel jobs
# to use.
CMake: Enable LLVM_COMPILER_JOBS on all MS IDEs. We don't support older environments than VS9. llvm-svn: 155285
2012-04-21 22:51:02 +08:00
if( MSVC_IDE )
Support for parallel compilation (/MP) when using the VS IDE. Patch by Erik Olofsson! llvm-svn: 126847
2011-03-03 01:47:37 +08:00
set(LLVM_COMPILER_JOBS "0" CACHE STRING
"Number of parallel compiler jobs. 0 means use all processors. Default is 0.")
if( NOT LLVM_COMPILER_JOBS STREQUAL "1" )
if( LLVM_COMPILER_JOBS STREQUAL "0" )
Fix evaluation of LLVM_DEFINITIONS CMake variable LLVM_DEFINITIONS collects preprocessor definitions provided for host compiler that builds llvm components. A function add_llvm_definitions was introduced in AddLLVMDefinitions.cmake to keep track of these definitions and was intended to be a replacement for CMake command add_definitions. Actually in many cases add_definitions is still used and the content of LLVM_DEFINITIONS is not actual now. On the other hand the current version of CMake allows getting set of definitions in a more convenient way. This fix implements evaluation of the variable by reading corresponding cmake property. Differential Revision: https://reviews.llvm.org/D31125 llvm-svn: 298336
2017-03-21 12:03:24 +08:00
add_definitions( /MP )
Support for parallel compilation (/MP) when using the VS IDE. Patch by Erik Olofsson! llvm-svn: 126847
2011-03-03 01:47:37 +08:00
else()
Remove cmake module support for Visual C++ 2010 (MSVC10) but keep the MSVC11 (Visual C++ 2012) support. llvm-svn: 204706
2014-03-25 17:34:20 +08:00
message(STATUS "Number of parallel compiler jobs set to " ${LLVM_COMPILER_JOBS})
Fix evaluation of LLVM_DEFINITIONS CMake variable LLVM_DEFINITIONS collects preprocessor definitions provided for host compiler that builds llvm components. A function add_llvm_definitions was introduced in AddLLVMDefinitions.cmake to keep track of these definitions and was intended to be a replacement for CMake command add_definitions. Actually in many cases add_definitions is still used and the content of LLVM_DEFINITIONS is not actual now. On the other hand the current version of CMake allows getting set of definitions in a more convenient way. This fix implements evaluation of the variable by reading corresponding cmake property. Differential Revision: https://reviews.llvm.org/D31125 llvm-svn: 298336
2017-03-21 12:03:24 +08:00
add_definitions( /MP${LLVM_COMPILER_JOBS} )
Support for parallel compilation (/MP) when using the VS IDE. Patch by Erik Olofsson! llvm-svn: 126847
2011-03-03 01:47:37 +08:00
endif()
else()
message(STATUS "Parallel compilation disabled")
endif()
endif()
[CMake] Increase stack size to 16MiB for all mingw executables. llvm-svn: 280303
2016-09-01 06:43:23 +08:00
# set stack reserved size to ~10MB
if(MSVC)
# CMake previously automatically set this value for MSVC builds, but the
# behavior was changed in CMake 2.8.11 (Issue 12437) to use the MSVC default
# value (1 MB) which is not enough for us in tasks such as parsing recursive
# C++ templates in Clang.
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} /STACK:10000000")
elseif(MINGW) # FIXME: Also cygwin?
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -Wl,--stack,16777216")
Pass -Wa,-mbig-obj in 64-bit mingw builds COFF has a 2**16 section limit, and on Win64, every COMDAT function creates at least 3 sections: .text, .pdata, and .xdata. For MSVC, we enable bigobj on a file-by-file basis, but GCC appears to hit the limit on different files. Fixes PR25953 llvm-svn: 290358
2016-12-23 03:12:14 +08:00
# Pass -mbig-obj to mingw gas on Win64. COFF has a 2**16 section limit, and
# on Win64, every COMDAT function creates at least 3 sections: .text, .pdata,
# and .xdata.
if (CMAKE_SIZEOF_VOID_P EQUAL 8)
append("-Wa,-mbig-obj" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
endif()
[CMake] Increase stack size to 16MiB for all mingw executables. llvm-svn: 280303
2016-09-01 06:43:23 +08:00
endif()
Changes for building Clang and others using LLVM as an external library. Installs tblgen (required by Clang). Translates handling of user settings and platform-dependant options to its own file, where it can included by another project. Installs the .cmake files required by projects like Clang. llvm-svn: 124816
2011-02-04 04:57:36 +08:00
if( MSVC )
include(ChooseMSVCCRT)
# Add definitions that make MSVC much less annoying.
Fix evaluation of LLVM_DEFINITIONS CMake variable LLVM_DEFINITIONS collects preprocessor definitions provided for host compiler that builds llvm components. A function add_llvm_definitions was introduced in AddLLVMDefinitions.cmake to keep track of these definitions and was intended to be a replacement for CMake command add_definitions. Actually in many cases add_definitions is still used and the content of LLVM_DEFINITIONS is not actual now. On the other hand the current version of CMake allows getting set of definitions in a more convenient way. This fix implements evaluation of the variable by reading corresponding cmake property. Differential Revision: https://reviews.llvm.org/D31125 llvm-svn: 298336
2017-03-21 12:03:24 +08:00
add_definitions(
Changes for building Clang and others using LLVM as an external library. Installs tblgen (required by Clang). Translates handling of user settings and platform-dependant options to its own file, where it can included by another project. Installs the .cmake files required by projects like Clang. llvm-svn: 124816
2011-02-04 04:57:36 +08:00
# For some reason MS wants to deprecate a bunch of standard functions...
-D_CRT_SECURE_NO_DEPRECATE
-D_CRT_SECURE_NO_WARNINGS
-D_CRT_NONSTDC_NO_DEPRECATE
-D_CRT_NONSTDC_NO_WARNINGS
-D_SCL_SECURE_NO_DEPRECATE
-D_SCL_SECURE_NO_WARNINGS
[CMake] Don't pass in MSVC warning flags as definitions. NFC currently but required as a prerequisite for using the Microsoft resource compiler in conjunction with CMake's ninja generator, which knows how to filter flags appropriately, but not definitions. Differential Revision: http://reviews.llvm.org/D8188 llvm-svn: 232727
2015-03-20 00:32:47 +08:00
)
Changes for building Clang and others using LLVM as an external library. Installs tblgen (required by Clang). Translates handling of user settings and platform-dependant options to its own file, where it can included by another project. Installs the .cmake files required by projects like Clang. llvm-svn: 124816
2011-02-04 04:57:36 +08:00
Default to using the Unicode version of Win32 APIs instead of the ANSI version. This helps to catch instances where a developer accidentally forgets to explicitly specify which version of the API to use and accidentally winds up failing to support non-ASCII characters properly. llvm-svn: 273599
2016-06-24 03:02:09 +08:00
# Tell MSVC to use the Unicode version of the Win32 APIs instead of ANSI.
Fix evaluation of LLVM_DEFINITIONS CMake variable LLVM_DEFINITIONS collects preprocessor definitions provided for host compiler that builds llvm components. A function add_llvm_definitions was introduced in AddLLVMDefinitions.cmake to keep track of these definitions and was intended to be a replacement for CMake command add_definitions. Actually in many cases add_definitions is still used and the content of LLVM_DEFINITIONS is not actual now. On the other hand the current version of CMake allows getting set of definitions in a more convenient way. This fix implements evaluation of the variable by reading corresponding cmake property. Differential Revision: https://reviews.llvm.org/D31125 llvm-svn: 298336
2017-03-21 12:03:24 +08:00
add_definitions(
Default to using the Unicode version of Win32 APIs instead of the ANSI version. This helps to catch instances where a developer accidentally forgets to explicitly specify which version of the API to use and accidentally winds up failing to support non-ASCII characters properly. llvm-svn: 273599
2016-06-24 03:02:09 +08:00
-DUNICODE
-D_UNICODE
)
Changes for building Clang and others using LLVM as an external library. Installs tblgen (required by Clang). Translates handling of user settings and platform-dependant options to its own file, where it can included by another project. Installs the .cmake files required by projects like Clang. llvm-svn: 124816
2011-02-04 04:57:36 +08:00
if (LLVM_ENABLE_WERROR)
[cmake] Refactor warning flag logic to use Unix warnings with clang-cl Summary: clang-cl understands the GCC-style -W[no-]foo flags, and for the most part ignores MSVC -wd flags. So, let's pass the curated set of warning flags we use on Unix on Windows. We can also stop passing /W4 -wd*, which for the most part corresponds to -Wall -Wextra with a bunch of flags that we mostly ignore. I had to disable -Wnon-virtual-dtor on Windows, because it fires on every COM class ever. I filed PR32286 to fix this. So far I've only found two instances of -Wstring-conversion in the WinASan code, which I'll fix. Other than that we seem clean. Reviewers: hans Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D30992 llvm-svn: 297964
2017-03-17 01:05:16 +08:00
append("/WX" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
Changes for building Clang and others using LLVM as an external library. Installs tblgen (required by Clang). Translates handling of user settings and platform-dependant options to its own file, where it can included by another project. Installs the .cmake files required by projects like Clang. llvm-svn: 124816
2011-02-04 04:57:36 +08:00
endif (LLVM_ENABLE_WERROR)
[CMake] Don't pass in MSVC warning flags as definitions. NFC currently but required as a prerequisite for using the Microsoft resource compiler in conjunction with CMake's ninja generator, which knows how to filter flags appropriately, but not definitions. Differential Revision: http://reviews.llvm.org/D8188 llvm-svn: 232727
2015-03-20 00:32:47 +08:00
Use /Zc:inline when building with MSVC. This reduces the total .obj size when building llvm from 496,690,342 to 219,334,936 bytes. llvm-svn: 244767
2015-08-13 01:09:25 +08:00
append("/Zc:inline" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
Don't make PDBs by default in Release mode Introduce the LLVM_ENABLE_PDB option so that users can request them explicitly instead. Add /OPT:REF and /OPT:ICF back, which /DEBUG disables by default. Differential Revision: https://reviews.llvm.org/D43156 llvm-svn: 325296
2018-02-16 05:25:23 +08:00
# Allow users to request PDBs in release mode. CMake offeres the
# RelWithDebInfo configuration, but it uses different optimization settings
# (/Ob1 vs /Ob2 or -O2 vs -O3). LLVM provides this flag so that users can get
# PDBs without changing codegen.
option(LLVM_ENABLE_PDB OFF)
if (LLVM_ENABLE_PDB AND uppercase_CMAKE_BUILD_TYPE STREQUAL "RELEASE")
Generate PDB files for profiling even in Release build. This patch enables PDB generation for Release build, which has slightly different optimize option with RelWithDebInfo on windows. This helps to know slow part of Release build when profiling. Patch by Takuto Ikuta Differential Revision: https://reviews.llvm.org/D42632 llvm-svn: 324504
2018-02-08 03:37:52 +08:00
append("/Zi" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
Don't make PDBs by default in Release mode Introduce the LLVM_ENABLE_PDB option so that users can request them explicitly instead. Add /OPT:REF and /OPT:ICF back, which /DEBUG disables by default. Differential Revision: https://reviews.llvm.org/D43156 llvm-svn: 325296
2018-02-16 05:25:23 +08:00
# /DEBUG disables linker GC and ICF, but we want those in Release mode.
append("/DEBUG /OPT:REF /OPT:ICF"
CMAKE_EXE_LINKER_FLAGS CMAKE_MODULE_LINKER_FLAGS
CMAKE_SHARED_LINKER_FLAGS)
endif()
Generate PDB files for profiling even in Release build. This patch enables PDB generation for Release build, which has slightly different optimize option with RelWithDebInfo on windows. This helps to know slow part of Release build when profiling. Patch by Takuto Ikuta Differential Revision: https://reviews.llvm.org/D42632 llvm-svn: 324504
2018-02-08 03:37:52 +08:00
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-31 06:49:11 +08:00
# Disable string literal const->non-const type conversion.
# "When specified, the compiler requires strict const-qualification
# conformance for pointers initialized by using string literals."
append("/Zc:strictStrings" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
Reapplying r256836 with a fix for MSVC 14 support. Enable more strict standards conformance in MSVC for rvalue casting and string literal type conversion to non-const types. Also enables generation of intrinsics for more functions. Patch by Alexander Riccio llvm-svn: 258687
2016-01-25 22:17:39 +08:00
# "Generate Intrinsic Functions".
append("/Oi" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
# "Enforce type conversion rules".
append("/Zc:rvalueCast" CMAKE_CXX_FLAGS)
enable building with LTO on Windows using clang-cl and lld Summary: With clang-cl gaining support for link-time optimization, we can now enable builds using LTO when using clang-cl and lld on Windows. To do this, we must not pass the -flto flag to the linker; lld-link does not understand it, but will perform LTO automatically when it encounters bitcode files. We also don't pass /Brepro when using LTO - the compiler doesn't generate object files for LTO, so passing the flag would only result in a warning about it being unused. Reviewers: rnk, ruiu, hans Reviewed By: hans Subscribers: mgorny, mehdi_amini, llvm-commits Differential Revision: https://reviews.llvm.org/D30240 llvm-svn: 296658
2017-03-02 03:22:18 +08:00
if (CMAKE_CXX_COMPILER_ID MATCHES "Clang" AND NOT LLVM_ENABLE_LTO)
Make WinCOFFObjectWriter.cpp's timestamp writing not use ENABLE_TIMESTAMPS LLVM_ENABLE_TIMESTAMPS controls if timestamps are embedded into llvm's binaries. Turning it off is useful for deterministic builds. r246905 made it so that the define suddenly also controls if the binaries that the llvm binaries _create_ embed timestamps or not – but this shouldn't be a configure-time option. r256203/r256204 added a driver option to toggle this on and off, so this patch now passes this driver option in LLVM_ENABLE_TIMESTAMPS builds so that if LLVM_ENABLE_TIMESTAMPS is set, the build of LLVM is deterministic – but the built clang can still write timestamps into other executables when requested. This also allows removing some of the test machinery added in r292012 to work around this problem. See PR24740 for background. http://reviews.llvm.org/D15783 llvm-svn: 256958
2016-01-07 03:05:19 +08:00
# clang-cl and cl by default produce non-deterministic binaries because
# link.exe /incremental requires a timestamp in the .obj file. clang-cl
Remove LLVM_ENABLE_TIMESTAMPS Summary: As per the discussion on LLVM-dev this patch proposes removing LLVM_ENABLE_TIMESTAMPS. The only complicated bit of this patch is the Windows support. On windows we used to log an error if /INCREMENTAL was passed to the linker when timestamps were disabled. With this change since timestamps in code are always disabled we will always compile on windows with /Brepro unless /INCREMENTAL is specified, and we will log a warning when /INCREMENTAL is specified to notify the user that the build will be non-deterministic. See: http://lists.llvm.org/pipermail/llvm-dev/2016-May/098990.html Reviewers: bogner, silvas, rnk Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D19892 llvm-svn: 268670
2016-05-06 03:57:03 +08:00
# has the flag /Brepro to force deterministic binaries. We want to pass that
enable building with LTO on Windows using clang-cl and lld Summary: With clang-cl gaining support for link-time optimization, we can now enable builds using LTO when using clang-cl and lld on Windows. To do this, we must not pass the -flto flag to the linker; lld-link does not understand it, but will perform LTO automatically when it encounters bitcode files. We also don't pass /Brepro when using LTO - the compiler doesn't generate object files for LTO, so passing the flag would only result in a warning about it being unused. Reviewers: rnk, ruiu, hans Reviewed By: hans Subscribers: mgorny, mehdi_amini, llvm-commits Differential Revision: https://reviews.llvm.org/D30240 llvm-svn: 296658
2017-03-02 03:22:18 +08:00
# whenever you're building with clang unless you're passing /incremental
# or using LTO (/Brepro with LTO would result in a warning about the flag
# being unused, because we're not generating object files).
Make WinCOFFObjectWriter.cpp's timestamp writing not use ENABLE_TIMESTAMPS LLVM_ENABLE_TIMESTAMPS controls if timestamps are embedded into llvm's binaries. Turning it off is useful for deterministic builds. r246905 made it so that the define suddenly also controls if the binaries that the llvm binaries _create_ embed timestamps or not – but this shouldn't be a configure-time option. r256203/r256204 added a driver option to toggle this on and off, so this patch now passes this driver option in LLVM_ENABLE_TIMESTAMPS builds so that if LLVM_ENABLE_TIMESTAMPS is set, the build of LLVM is deterministic – but the built clang can still write timestamps into other executables when requested. This also allows removing some of the test machinery added in r292012 to work around this problem. See PR24740 for background. http://reviews.llvm.org/D15783 llvm-svn: 256958
2016-01-07 03:05:19 +08:00
# This checks CMAKE_CXX_COMPILER_ID in addition to check_cxx_compiler_flag()
# because cl.exe does not emit an error on flags it doesn't understand,
# letting check_cxx_compiler_flag() claim it understands all flags.
check_cxx_compiler_flag("/Brepro" SUPPORTS_BREPRO)
if (SUPPORTS_BREPRO)
# Check if /INCREMENTAL is passed to the linker and complain that it
# won't work with /Brepro.
string(TOUPPER "${CMAKE_EXE_LINKER_FLAGS}" upper_exe_flags)
string(TOUPPER "${CMAKE_MODULE_LINKER_FLAGS}" upper_module_flags)
string(TOUPPER "${CMAKE_SHARED_LINKER_FLAGS}" upper_shared_flags)
Remove LLVM_ENABLE_TIMESTAMPS Summary: As per the discussion on LLVM-dev this patch proposes removing LLVM_ENABLE_TIMESTAMPS. The only complicated bit of this patch is the Windows support. On windows we used to log an error if /INCREMENTAL was passed to the linker when timestamps were disabled. With this change since timestamps in code are always disabled we will always compile on windows with /Brepro unless /INCREMENTAL is specified, and we will log a warning when /INCREMENTAL is specified to notify the user that the build will be non-deterministic. See: http://lists.llvm.org/pipermail/llvm-dev/2016-May/098990.html Reviewers: bogner, silvas, rnk Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D19892 llvm-svn: 268670
2016-05-06 03:57:03 +08:00
string(FIND "${upper_exe_flags} ${upper_module_flags} ${upper_shared_flags}"
"/INCREMENTAL" linker_flag_idx)
Disable 64bit file position on old 32 bit Androids. This is needed for building LLVM on Android with new NDK (newer than r15c) and API level < 24. Android C library (Bionic) didn't have support for 64 bit file position until Android N. Differential Revision: https://reviews.llvm.org/D37314 llvm-svn: 312389
2017-09-02 07:12:43 +08:00
Remove LLVM_ENABLE_TIMESTAMPS Summary: As per the discussion on LLVM-dev this patch proposes removing LLVM_ENABLE_TIMESTAMPS. The only complicated bit of this patch is the Windows support. On windows we used to log an error if /INCREMENTAL was passed to the linker when timestamps were disabled. With this change since timestamps in code are always disabled we will always compile on windows with /Brepro unless /INCREMENTAL is specified, and we will log a warning when /INCREMENTAL is specified to notify the user that the build will be non-deterministic. See: http://lists.llvm.org/pipermail/llvm-dev/2016-May/098990.html Reviewers: bogner, silvas, rnk Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D19892 llvm-svn: 268670
2016-05-06 03:57:03 +08:00
if (${linker_flag_idx} GREATER -1)
message(WARNING "/Brepro not compatible with /INCREMENTAL linking - builds will be non-deterministic")
else()
append("/Brepro" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
Make WinCOFFObjectWriter.cpp's timestamp writing not use ENABLE_TIMESTAMPS LLVM_ENABLE_TIMESTAMPS controls if timestamps are embedded into llvm's binaries. Turning it off is useful for deterministic builds. r246905 made it so that the define suddenly also controls if the binaries that the llvm binaries _create_ embed timestamps or not – but this shouldn't be a configure-time option. r256203/r256204 added a driver option to toggle this on and off, so this patch now passes this driver option in LLVM_ENABLE_TIMESTAMPS builds so that if LLVM_ENABLE_TIMESTAMPS is set, the build of LLVM is deterministic – but the built clang can still write timestamps into other executables when requested. This also allows removing some of the test machinery added in r292012 to work around this problem. See PR24740 for background. http://reviews.llvm.org/D15783 llvm-svn: 256958
2016-01-07 03:05:19 +08:00
endif()
endif()
endif()
[cmake] Move blocks out of redundant else( MSVC ); NFC Address post-commit comment on D66256 regarding the `else( MSVC )` block containing only blocks guarded with `LLVM_COMPILER_IS_GCC_COMPATIBLE`, which would imply `NOT MSVC`. llvm-svn: 369221
2019-08-19 06:02:24 +08:00
endif( MSVC )
Make WinCOFFObjectWriter.cpp's timestamp writing not use ENABLE_TIMESTAMPS LLVM_ENABLE_TIMESTAMPS controls if timestamps are embedded into llvm's binaries. Turning it off is useful for deterministic builds. r246905 made it so that the define suddenly also controls if the binaries that the llvm binaries _create_ embed timestamps or not – but this shouldn't be a configure-time option. r256203/r256204 added a driver option to toggle this on and off, so this patch now passes this driver option in LLVM_ENABLE_TIMESTAMPS builds so that if LLVM_ENABLE_TIMESTAMPS is set, the build of LLVM is deterministic – but the built clang can still write timestamps into other executables when requested. This also allows removing some of the test machinery added in r292012 to work around this problem. See PR24740 for background. http://reviews.llvm.org/D15783 llvm-svn: 256958
2016-01-07 03:05:19 +08:00
[cmake] Move blocks out of redundant else( MSVC ); NFC Address post-commit comment on D66256 regarding the `else( MSVC )` block containing only blocks guarded with `LLVM_COMPILER_IS_GCC_COMPATIBLE`, which would imply `NOT MSVC`. llvm-svn: 369221
2019-08-19 06:02:24 +08:00
# Warnings-as-errors handling for GCC-compatible compilers:
if ( LLVM_COMPILER_IS_GCC_COMPATIBLE )
append_if(LLVM_ENABLE_WERROR "-Werror" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
append_if(LLVM_ENABLE_WERROR "-Wno-error" CMAKE_REQUIRED_FLAGS)
endif( LLVM_COMPILER_IS_GCC_COMPATIBLE )
# Specific default warnings-as-errors for compilers accepting GCC-compatible warning flags:
if ( LLVM_COMPILER_IS_GCC_COMPATIBLE OR CMAKE_CXX_COMPILER_ID MATCHES "XL" )
add_flag_if_supported("-Werror=date-time" WERROR_DATE_TIME)
add_flag_if_supported("-Werror=unguarded-availability-new" WERROR_UNGUARDED_AVAILABILITY_NEW)
endif( LLVM_COMPILER_IS_GCC_COMPATIBLE OR CMAKE_CXX_COMPILER_ID MATCHES "XL" )
# Modules enablement for GCC-compatible compilers:
if ( LLVM_COMPILER_IS_GCC_COMPATIBLE AND LLVM_ENABLE_MODULES )
set(OLD_CMAKE_REQUIRED_FLAGS ${CMAKE_REQUIRED_FLAGS})
set(module_flags "-fmodules -fmodules-cache-path=${PROJECT_BINARY_DIR}/module.cache")
if (${CMAKE_SYSTEM_NAME} MATCHES "Darwin")
# On Darwin -fmodules does not imply -fcxx-modules.
set(module_flags "${module_flags} -fcxx-modules")
endif()
if (LLVM_ENABLE_LOCAL_SUBMODULE_VISIBILITY)
set(module_flags "${module_flags} -Xclang -fmodules-local-submodule-visibility")
endif()
if (LLVM_ENABLE_MODULE_DEBUGGING AND
((uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG") OR
(uppercase_CMAKE_BUILD_TYPE STREQUAL "RELWITHDEBINFO")))
set(module_flags "${module_flags} -gmodules")
endif()
set(CMAKE_REQUIRED_FLAGS "${CMAKE_REQUIRED_FLAGS} ${module_flags}")
# Check that we can build code with modules enabled, and that repeatedly
# including <cassert> still manages to respect NDEBUG properly.
CHECK_CXX_SOURCE_COMPILES("#undef NDEBUG
#include <cassert>
#define NDEBUG
#include <cassert>
int main() { assert(this code is not compiled); }"
CXX_SUPPORTS_MODULES)
set(CMAKE_REQUIRED_FLAGS ${OLD_CMAKE_REQUIRED_FLAGS})
if (CXX_SUPPORTS_MODULES)
append("${module_flags}" CMAKE_CXX_FLAGS)
else()
message(FATAL_ERROR "LLVM_ENABLE_MODULES is not supported by this compiler")
endif()
endif( LLVM_COMPILER_IS_GCC_COMPATIBLE AND LLVM_ENABLE_MODULES )
Changes for building Clang and others using LLVM as an external library. Installs tblgen (required by Clang). Translates handling of user settings and platform-dependant options to its own file, where it can included by another project. Installs the .cmake files required by projects like Clang. llvm-svn: 124816
2011-02-04 04:57:36 +08:00
[cmake] Replace -Wall with /W4 in clang-cl options now that -Wall aliases -Weverything Instead, reuse the code-path for cl.exe that adds /W4 , which for clang-cl aliases clang's "-Wall -Wextra" which matches what clang-cl's /Wall previously aliased. This should restore the verbosity of a Windows selfhost build back to its previous levels. Differential Revision: https://reviews.llvm.org/D40603 llvm-svn: 319330
2017-11-30 02:05:32 +08:00
if (MSVC)
if (NOT CLANG_CL)
set(msvc_warning_flags
# Disabled warnings.
-wd4141 # Suppress ''modifier' : used more than once' (because of __forceinline combined with inline)
-wd4146 # Suppress 'unary minus operator applied to unsigned type, result still unsigned'
-wd4244 # Suppress ''argument' : conversion from 'type1' to 'type2', possible loss of data'
-wd4267 # Suppress ''var' : conversion from 'size_t' to 'type', possible loss of data'
-wd4291 # Suppress ''declaration' : no matching operator delete found; memory will not be freed if initialization throws an exception'
-wd4351 # Suppress 'new behavior: elements of array 'array' will be default initialized'
-wd4456 # Suppress 'declaration of 'var' hides local variable'
-wd4457 # Suppress 'declaration of 'var' hides function parameter'
-wd4458 # Suppress 'declaration of 'var' hides class member'
-wd4459 # Suppress 'declaration of 'var' hides global declaration'
-wd4503 # Suppress ''identifier' : decorated name length exceeded, name was truncated'
-wd4624 # Suppress ''derived class' : destructor could not be generated because a base class destructor is inaccessible'
-wd4722 # Suppress 'function' : destructor never returns, potential memory leak
-wd4100 # Suppress 'unreferenced formal parameter'
-wd4127 # Suppress 'conditional expression is constant'
-wd4512 # Suppress 'assignment operator could not be generated'
-wd4505 # Suppress 'unreferenced local function has been removed'
-wd4610 # Suppress '<class> can never be instantiated'
-wd4510 # Suppress 'default constructor could not be generated'
-wd4702 # Suppress 'unreachable code'
[cmake] Improve comment describing the C4245 warning. NFCI. llvm-svn: 370772
2019-09-04 00:11:37 +08:00
-wd4245 # Suppress ''conversion' : conversion from 'type1' to 'type2', signed/unsigned mismatch'
[cmake] Replace -Wall with /W4 in clang-cl options now that -Wall aliases -Weverything Instead, reuse the code-path for cl.exe that adds /W4 , which for clang-cl aliases clang's "-Wall -Wextra" which matches what clang-cl's /Wall previously aliased. This should restore the verbosity of a Windows selfhost build back to its previous levels. Differential Revision: https://reviews.llvm.org/D40603 llvm-svn: 319330
2017-11-30 02:05:32 +08:00
-wd4706 # Suppress 'assignment within conditional expression'
-wd4310 # Suppress 'cast truncates constant value'
-wd4701 # Suppress 'potentially uninitialized local variable'
-wd4703 # Suppress 'potentially uninitialized local pointer variable'
-wd4389 # Suppress 'signed/unsigned mismatch'
-wd4611 # Suppress 'interaction between '_setjmp' and C++ object destruction is non-portable'
-wd4805 # Suppress 'unsafe mix of type <type> and type <type> in operation'
-wd4204 # Suppress 'nonstandard extension used : non-constant aggregate initializer'
-wd4577 # Suppress 'noexcept used with no exception handling mode specified; termination on exception is not guaranteed'
-wd4091 # Suppress 'typedef: ignored on left of '' when no variable is declared'
# C4592 is disabled because of false positives in Visual Studio 2015
# Update 1. Re-evaluate the usefulness of this diagnostic with Update 2.
-wd4592 # Suppress ''var': symbol will be dynamically initialized (implementation limitation)
-wd4319 # Suppress ''operator' : zero extending 'type' to 'type' of greater size'
Silence C4709 in MSVC because it is buggy. The diagnostic will trigger on code that does not have any comma operator, but instead default-constructs an object with an explicitly defaulted constructor as the array index argument. llvm-svn: 347345
2018-11-21 04:50:04 +08:00
# C4709 is disabled because of a bug with Visual Studio 2017 as of
# v15.8.8. Re-evaluate the usefulness of this diagnostic when the bug
# is fixed.
-wd4709 # Suppress comma operator within array index expression
[cmake] Replace -Wall with /W4 in clang-cl options now that -Wall aliases -Weverything Instead, reuse the code-path for cl.exe that adds /W4 , which for clang-cl aliases clang's "-Wall -Wextra" which matches what clang-cl's /Wall previously aliased. This should restore the verbosity of a Windows selfhost build back to its previous levels. Differential Revision: https://reviews.llvm.org/D40603 llvm-svn: 319330
2017-11-30 02:05:32 +08:00
[CMake] Update C4324 MSVC warning comment to explain its still broken at VS2019 As promised, I've updated the comment for the C4324 MSVC warning that was re-disabled at rL367409 / rG8f823e63e3edf87ab029ba32b68f3eb5d2f392b5 to put it in terms of currently supported VS versions llvm-svn: 369368
2019-08-20 19:20:05 +08:00
# Ideally, we'd like this warning to be enabled, but even MSVC 2019 doesn't
Re-disable C4324 MSVC warning that was enabled in D65458 / rL367383 This was breaking /WX builds llvm-svn: 367409
2019-07-31 19:06:05 +08:00
# support the 'aligned' attribute in the way that clang sources requires (for
# any code that uses the LLVM_ALIGNAS macro), so this is must be disabled to
# avoid unwanted alignment warnings.
-wd4324 # Suppress 'structure was padded due to __declspec(align())'
[cmake] Replace -Wall with /W4 in clang-cl options now that -Wall aliases -Weverything Instead, reuse the code-path for cl.exe that adds /W4 , which for clang-cl aliases clang's "-Wall -Wextra" which matches what clang-cl's /Wall previously aliased. This should restore the verbosity of a Windows selfhost build back to its previous levels. Differential Revision: https://reviews.llvm.org/D40603 llvm-svn: 319330
2017-11-30 02:05:32 +08:00
# Promoted warnings.
-w14062 # Promote 'enumerator in switch of enum is not handled' to level 1 warning.
# Promoted warnings to errors.
-we4238 # Promote 'nonstandard extension used : class rvalue used as lvalue' to error.
)
endif(NOT CLANG_CL)
[cmake] Refactor warning flag logic to use Unix warnings with clang-cl Summary: clang-cl understands the GCC-style -W[no-]foo flags, and for the most part ignores MSVC -wd flags. So, let's pass the curated set of warning flags we use on Unix on Windows. We can also stop passing /W4 -wd*, which for the most part corresponds to -Wall -Wextra with a bunch of flags that we mostly ignore. I had to disable -Wnon-virtual-dtor on Windows, because it fires on every COM class ever. I filed PR32286 to fix this. So far I've only found two instances of -Wstring-conversion in the WinASan code, which I'll fix. Other than that we seem clean. Reviewers: hans Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D30992 llvm-svn: 297964
2017-03-17 01:05:16 +08:00
# Enable warnings
if (LLVM_ENABLE_WARNINGS)
# Put /W4 in front of all the -we flags. cl.exe doesn't care, but for
# clang-cl having /W4 after the -we flags will re-enable the warnings
# disabled by -we.
set(msvc_warning_flags "/W4 ${msvc_warning_flags}")
# CMake appends /W3 by default, and having /W3 followed by /W4 will result in
# cl : Command line warning D9025 : overriding '/W3' with '/W4'. Since this is
# a command line warning and not a compiler warning, it cannot be suppressed except
# by fixing the command line.
string(REGEX REPLACE " /W[0-4]" "" CMAKE_C_FLAGS "${CMAKE_C_FLAGS}")
string(REGEX REPLACE " /W[0-4]" "" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
if (LLVM_ENABLE_PEDANTIC)
# No MSVC equivalent available
endif (LLVM_ENABLE_PEDANTIC)
endif (LLVM_ENABLE_WARNINGS)
foreach(flag ${msvc_warning_flags})
append("${flag}" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
endforeach(flag)
[cmake] Replace -Wall with /W4 in clang-cl options now that -Wall aliases -Weverything Instead, reuse the code-path for cl.exe that adds /W4 , which for clang-cl aliases clang's "-Wall -Wextra" which matches what clang-cl's /Wall previously aliased. This should restore the verbosity of a Windows selfhost build back to its previous levels. Differential Revision: https://reviews.llvm.org/D40603 llvm-svn: 319330
2017-11-30 02:05:32 +08:00
endif (MSVC)
[cmake] Refactor warning flag logic to use Unix warnings with clang-cl Summary: clang-cl understands the GCC-style -W[no-]foo flags, and for the most part ignores MSVC -wd flags. So, let's pass the curated set of warning flags we use on Unix on Windows. We can also stop passing /W4 -wd*, which for the most part corresponds to -Wall -Wextra with a bunch of flags that we mostly ignore. I had to disable -Wnon-virtual-dtor on Windows, because it fires on every COM class ever. I filed PR32286 to fix this. So far I've only found two instances of -Wstring-conversion in the WinASan code, which I'll fix. Other than that we seem clean. Reviewers: hans Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D30992 llvm-svn: 297964
2017-03-17 01:05:16 +08:00
if (LLVM_ENABLE_WARNINGS AND (LLVM_COMPILER_IS_GCC_COMPATIBLE OR CLANG_CL))
[cmake] Replace -Wall with /W4 in clang-cl options now that -Wall aliases -Weverything Instead, reuse the code-path for cl.exe that adds /W4 , which for clang-cl aliases clang's "-Wall -Wextra" which matches what clang-cl's /Wall previously aliased. This should restore the verbosity of a Windows selfhost build back to its previous levels. Differential Revision: https://reviews.llvm.org/D40603 llvm-svn: 319330
2017-11-30 02:05:32 +08:00
# Don't add -Wall for clang-cl, because it maps -Wall to -Weverything for
# MSVC compatibility. /W4 is added above instead.
if (NOT CLANG_CL)
append("-Wall" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
endif()
Use -Wextra spelling instead of -W No difference in behavior, but a bit easier to search for. https://reviews.llvm.org/D47490 llvm-svn: 333651
2018-05-31 21:41:04 +08:00
append("-Wextra -Wno-unused-parameter -Wwrite-strings" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
[cmake] Refactor warning flag logic to use Unix warnings with clang-cl Summary: clang-cl understands the GCC-style -W[no-]foo flags, and for the most part ignores MSVC -wd flags. So, let's pass the curated set of warning flags we use on Unix on Windows. We can also stop passing /W4 -wd*, which for the most part corresponds to -Wall -Wextra with a bunch of flags that we mostly ignore. I had to disable -Wnon-virtual-dtor on Windows, because it fires on every COM class ever. I filed PR32286 to fix this. So far I've only found two instances of -Wstring-conversion in the WinASan code, which I'll fix. Other than that we seem clean. Reviewers: hans Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D30992 llvm-svn: 297964
2017-03-17 01:05:16 +08:00
append("-Wcast-qual" CMAKE_CXX_FLAGS)
# Turn off missing field initializer warnings for gcc to avoid noise from
# false positives with empty {}. Turn them on otherwise (they're off by
# default for clang).
check_cxx_compiler_flag("-Wmissing-field-initializers" CXX_SUPPORTS_MISSING_FIELD_INITIALIZERS_FLAG)
if (CXX_SUPPORTS_MISSING_FIELD_INITIALIZERS_FLAG)
if (CMAKE_COMPILER_IS_GNUCXX)
append("-Wno-missing-field-initializers" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
else()
append("-Wmissing-field-initializers" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
endif()
endif()
if (LLVM_ENABLE_PEDANTIC AND LLVM_COMPILER_IS_GCC_COMPATIBLE)
append("-pedantic" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
append("-Wno-long-long" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
endif()
Enable -Wimplicit-fallthrough for clang as well as GCC All instances of this warning should already be fixed across all LLVM subprojects, at least on Linux. llvm-svn: 345887
2018-11-02 04:31:44 +08:00
add_flag_if_supported("-Wimplicit-fallthrough" IMPLICIT_FALLTHROUGH_FLAG)
[cmake] Refactor warning flag logic to use Unix warnings with clang-cl Summary: clang-cl understands the GCC-style -W[no-]foo flags, and for the most part ignores MSVC -wd flags. So, let's pass the curated set of warning flags we use on Unix on Windows. We can also stop passing /W4 -wd*, which for the most part corresponds to -Wall -Wextra with a bunch of flags that we mostly ignore. I had to disable -Wnon-virtual-dtor on Windows, because it fires on every COM class ever. I filed PR32286 to fix this. So far I've only found two instances of -Wstring-conversion in the WinASan code, which I'll fix. Other than that we seem clean. Reviewers: hans Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D30992 llvm-svn: 297964
2017-03-17 01:05:16 +08:00
add_flag_if_supported("-Wcovered-switch-default" COVERED_SWITCH_DEFAULT_FLAG)
append_if(USE_NO_UNINITIALIZED "-Wno-uninitialized" CMAKE_CXX_FLAGS)
append_if(USE_NO_MAYBE_UNINITIALIZED "-Wno-maybe-uninitialized" CMAKE_CXX_FLAGS)
Disable GCC's -Wclass-memaccess warning It fires on things like SmallVector<std::pair<int, int>>, where we intentionally use memcpy instead of calling the assignment operator. This warning fires in practically every LLVM TU, so we have to do something about it, even if we aren't interested in being 100% warning clean with GCC. Reported as PR37337 llvm-svn: 337492
2018-07-20 04:14:46 +08:00
# Disable -Wclass-memaccess, a C++-only warning from GCC 8 that fires on
# LLVM's ADT classes.
check_cxx_compiler_flag("-Wclass-memaccess" CXX_SUPPORTS_CLASS_MEMACCESS_FLAG)
append_if(CXX_SUPPORTS_CLASS_MEMACCESS_FLAG "-Wno-class-memaccess" CMAKE_CXX_FLAGS)
[cmake] Disable GCC 9's -Wredundant-move Summary: This new warning (enabled by -Wextra) fires when a std::move is redundant, as the default compiler behavior would be to select a move operation anyway (e.g., when returning a local variable). Unlike -Wpessimizing-move, it has no performance impact -- it just adds noise. Currently llvm has about 1500 of these warnings. Unfortunately, the suggested fix -- removing std::move -- does not work because of some older compilers we still support. Specifically clang<=3.8 will not use a move operation if an implicit conversion is needed (Core issue 1579). In code like "A f(ConvertibleToA a) { return a; }" it will prefer a copy, or fail to compile if a copy is not possible. This patch disables that warning to get a meaningful signal out of a GCC 9 build. Reviewers: rnk, aaron.ballman, xbolva00 Subscribers: mgorny, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70963
2019-11-29 21:44:28 +08:00
# Disable -Wredundant-move on GCC>=9. GCC wants to remove std::move in code
# like "A foo(ConvertibleToA a) { return std::move(a); }", but this code does
# not compile (or uses the copy constructor instead) on clang<=3.8. Clang also
# has a -Wredundant-move, but it only fires when the types match exactly, so
# we can keep it here.
if (CMAKE_CXX_COMPILER_ID STREQUAL "GNU")
check_cxx_compiler_flag("-Wredundant-move" CXX_SUPPORTS_REDUNDANT_MOVE_FLAG)
append_if(CXX_SUPPORTS_REDUNDANT_MOVE_FLAG "-Wno-redundant-move" CMAKE_CXX_FLAGS)
endif()
Disable -Wnoexcept-type due to false positives with GCC. GCC triggers false positives if a nothrow function is called through a template argument. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80985 for details. The LLVM libraries have no stable C++ API, so the warning is not useful. llvm-svn: 341361
2018-09-04 20:03:49 +08:00
# The LLVM libraries have no stable C++ API, so -Wnoexcept-type is not useful.
check_cxx_compiler_flag("-Wnoexcept-type" CXX_SUPPORTS_NOEXCEPT_TYPE_FLAG)
append_if(CXX_SUPPORTS_NOEXCEPT_TYPE_FLAG "-Wno-noexcept-type" CMAKE_CXX_FLAGS)
[cmake] Refactor warning flag logic to use Unix warnings with clang-cl Summary: clang-cl understands the GCC-style -W[no-]foo flags, and for the most part ignores MSVC -wd flags. So, let's pass the curated set of warning flags we use on Unix on Windows. We can also stop passing /W4 -wd*, which for the most part corresponds to -Wall -Wextra with a bunch of flags that we mostly ignore. I had to disable -Wnon-virtual-dtor on Windows, because it fires on every COM class ever. I filed PR32286 to fix this. So far I've only found two instances of -Wstring-conversion in the WinASan code, which I'll fix. Other than that we seem clean. Reviewers: hans Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D30992 llvm-svn: 297964
2017-03-17 01:05:16 +08:00
# Check if -Wnon-virtual-dtor warns even though the class is marked final.
# If it does, don't add it. So it won't be added on clang 3.4 and older.
# This also catches cases when -Wnon-virtual-dtor isn't supported by
# the compiler at all. This flag is not activated for gcc since it will
# incorrectly identify a protected non-virtual base when there is a friend
# declaration. Don't activate this in general on Windows as this warning has
# too many false positives on COM-style classes, which are destroyed with
# Release() (PR32286).
if (NOT CMAKE_COMPILER_IS_GNUCXX AND NOT WIN32)
set(OLD_CMAKE_REQUIRED_FLAGS ${CMAKE_REQUIRED_FLAGS})
set(CMAKE_REQUIRED_FLAGS "${CMAKE_REQUIRED_FLAGS} -std=c++11 -Werror=non-virtual-dtor")
CHECK_CXX_SOURCE_COMPILES("class base {public: virtual void anchor();protected: ~base();};
class derived final : public base { public: ~derived();};
int main() { return 0; }"
CXX_WONT_WARN_ON_FINAL_NONVIRTUALDTOR)
set(CMAKE_REQUIRED_FLAGS ${OLD_CMAKE_REQUIRED_FLAGS})
append_if(CXX_WONT_WARN_ON_FINAL_NONVIRTUALDTOR
"-Wnon-virtual-dtor" CMAKE_CXX_FLAGS)
endif()
# Enable -Wdelete-non-virtual-dtor if available.
add_flag_if_supported("-Wdelete-non-virtual-dtor" DELETE_NON_VIRTUAL_DTOR_FLAG)
# Check if -Wcomment is OK with an // comment ending with '\' if the next
# line is also a // comment.
set(OLD_CMAKE_REQUIRED_FLAGS ${CMAKE_REQUIRED_FLAGS})
set(CMAKE_REQUIRED_FLAGS "${CMAKE_REQUIRED_FLAGS} -Werror -Wcomment")
CHECK_C_SOURCE_COMPILES("// \\\\\\n//\\nint main() {return 0;}"
C_WCOMMENT_ALLOWS_LINE_WRAP)
set(CMAKE_REQUIRED_FLAGS ${OLD_CMAKE_REQUIRED_FLAGS})
if (NOT C_WCOMMENT_ALLOWS_LINE_WRAP)
append("-Wno-comment" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
endif()
# Enable -Wstring-conversion to catch misuse of string literals.
add_flag_if_supported("-Wstring-conversion" STRING_CONVERSION_FLAG)
endif (LLVM_ENABLE_WARNINGS AND (LLVM_COMPILER_IS_GCC_COMPATIBLE OR CLANG_CL))
Append -w when LLVM_ENABLE_WARNINGS is Off. Reviewed by rnk (D31702)! llvm-svn: 300100
2017-04-13 04:43:11 +08:00
if (LLVM_COMPILER_IS_GCC_COMPATIBLE AND NOT LLVM_ENABLE_WARNINGS)
append("-w" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
endif()
Add CMake option LLVM_USE_SANITIZER={Address,Memory,MemoryWithOrigins} to simplify bootstrap of LLVM/Clang under ASan/MSan llvm-svn: 177992
2013-03-26 15:49:46 +08:00
macro(append_common_sanitizer_flags)
[cmake] Start adding support for LLVM_USE_SANITIZER=Address on Windows Pass "-fsanitize=address" to the compiler and "-debug" to the linker. llvm-svn: 245070
2015-08-15 00:48:34 +08:00
if (NOT MSVC)
# Append -fno-omit-frame-pointer and turn on debug info to get better
# stack traces.
add_flag_if_supported("-fno-omit-frame-pointer" FNO_OMIT_FRAME_POINTER)
if (NOT uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG" AND
[cmake] Pass /manifest:no to the linker when asan is enabled This is a workaround for PR24476. llvm-svn: 245945
2015-08-26 00:06:40 +08:00
NOT uppercase_CMAKE_BUILD_TYPE STREQUAL "RELWITHDEBINFO")
[cmake] Start adding support for LLVM_USE_SANITIZER=Address on Windows Pass "-fsanitize=address" to the compiler and "-debug" to the linker. llvm-svn: 245070
2015-08-15 00:48:34 +08:00
add_flag_if_supported("-gline-tables-only" GLINE_TABLES_ONLY)
endif()
# Use -O1 even in debug mode, otherwise sanitizers slowdown is too large.
[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-18 00:55:29 +08:00
if (uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG" AND LLVM_OPTIMIZE_SANITIZED_BUILDS)
[cmake] Start adding support for LLVM_USE_SANITIZER=Address on Windows Pass "-fsanitize=address" to the compiler and "-debug" to the linker. llvm-svn: 245070
2015-08-15 00:48:34 +08:00
add_flag_if_supported("-O1" O1)
endif()
elseif (CLANG_CL)
# Keep frame pointers around.
append("/Oy-" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
# Always ask the linker to produce symbols with asan.
Tweaks for setting CMAKE_LINKER to lld-link - Just look for "lld-link", not "lld-link.exe". llvm/cmake/platforms/WinMsvc.cmake for example sets CMAKE_LINKER to lld-link without .exe - Stop passing -gwarf to the compiler in sanitizer options when lld is enabled -- there's no reason to use different debug information keyed off the linker. (If this was for MinGW, we should check for that instead.) Differential Revision: https://reviews.llvm.org/D62111 llvm-svn: 361214
2019-05-21 11:01:01 +08:00
append("/Z7" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
[cmake] Start adding support for LLVM_USE_SANITIZER=Address on Windows Pass "-fsanitize=address" to the compiler and "-debug" to the linker. llvm-svn: 245070
2015-08-15 00:48:34 +08:00
append("-debug" CMAKE_EXE_LINKER_FLAGS CMAKE_MODULE_LINKER_FLAGS CMAKE_SHARED_LINKER_FLAGS)
[CMake] Add -O1 in debug builds with LLVM_USE_SANITIZER llvm-svn: 189747
2013-09-02 17:15:01 +08:00
endif()
Add CMake option LLVM_USE_SANITIZER={Address,Memory,MemoryWithOrigins} to simplify bootstrap of LLVM/Clang under ASan/MSan llvm-svn: 177992
2013-03-26 15:49:46 +08:00
endmacro()
# Turn on sanitizers if necessary.
if(LLVM_USE_SANITIZER)
if (LLVM_ON_UNIX)
if (LLVM_USE_SANITIZER STREQUAL "Address")
append_common_sanitizer_flags()
Prospective -fsanitize=memory build fix following r212586 This -f group flag appears to influence linker flags, breaking the usual rules and causing CMake's link invocation to fail during feature detection due to missing link dependencies (msan_*). Let's forcibly add it for now to get things the way they were before feature detection started working. llvm-svn: 212590
2014-07-09 14:27:05 +08:00
append("-fsanitize=address" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
[HWASAN][CMake] Allow instrumenting LLVM/clang Differential revision: https://reviews.llvm.org/D62813 llvm-svn: 362474
2019-06-04 17:04:53 +08:00
elseif (LLVM_USE_SANITIZER STREQUAL "HWAddress")
append_common_sanitizer_flags()
append("-fsanitize=hwaddress" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
Add CMake option LLVM_USE_SANITIZER={Address,Memory,MemoryWithOrigins} to simplify bootstrap of LLVM/Clang under ASan/MSan llvm-svn: 177992
2013-03-26 15:49:46 +08:00
elseif (LLVM_USE_SANITIZER MATCHES "Memory(WithOrigins)?")
append_common_sanitizer_flags()
Prospective -fsanitize=memory build fix following r212586 This -f group flag appears to influence linker flags, breaking the usual rules and causing CMake's link invocation to fail during feature detection due to missing link dependencies (msan_*). Let's forcibly add it for now to get things the way they were before feature detection started working. llvm-svn: 212590
2014-07-09 14:27:05 +08:00
append("-fsanitize=memory" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
Add CMake option LLVM_USE_SANITIZER={Address,Memory,MemoryWithOrigins} to simplify bootstrap of LLVM/Clang under ASan/MSan llvm-svn: 177992
2013-03-26 15:49:46 +08:00
if(LLVM_USE_SANITIZER STREQUAL "MemoryWithOrigins")
Prospective -fsanitize=memory build fix following r212586 This -f group flag appears to influence linker flags, breaking the usual rules and causing CMake's link invocation to fail during feature detection due to missing link dependencies (msan_*). Let's forcibly add it for now to get things the way they were before feature detection started working. llvm-svn: 212590
2014-07-09 14:27:05 +08:00
append("-fsanitize-memory-track-origins" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
Add CMake option LLVM_USE_SANITIZER={Address,Memory,MemoryWithOrigins} to simplify bootstrap of LLVM/Clang under ASan/MSan llvm-svn: 177992
2013-03-26 15:49:46 +08:00
endif()
Introduce -DLLVM_USE_SANITIZER=Undefined CMake option to build UBSan-ified version of LLVM/Clang. I've fixed most of the simple bugs and currently "check-llvm" test suite has 26 failures, and "check-clang" suite has 5 failures. llvm-svn: 216701
2014-08-29 08:50:36 +08:00
elseif (LLVM_USE_SANITIZER STREQUAL "Undefined")
append_common_sanitizer_flags()
cmake: Use -fno-sanitize-recover=all - the old spelling is deprecated llvm-svn: 237334
2015-05-14 12:52:57 +08:00
append("-fsanitize=undefined -fno-sanitize=vptr,function -fno-sanitize-recover=all"
Introduce -DLLVM_USE_SANITIZER=Undefined CMake option to build UBSan-ified version of LLVM/Clang. I've fixed most of the simple bugs and currently "check-llvm" test suite has 26 failures, and "check-clang" suite has 5 failures. llvm-svn: 216701
2014-08-29 08:50:36 +08:00
CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
Add support for LLVM_USE_SANITIZER=Thread Summary: This will help in testing libc++ and libc++abi with tsan. Reviewers: samsonov Reviewed By: samsonov Subscribers: samsonov, llvm-commits Differential Revision: http://reviews.llvm.org/D6283 llvm-svn: 222258
2014-11-19 05:23:38 +08:00
elseif (LLVM_USE_SANITIZER STREQUAL "Thread")
append_common_sanitizer_flags()
append("-fsanitize=thread" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
[dfsan] Add "DataFlow" option to LLVM_USE_SANITIZER Summary: This patch add the dataflow option to LLVM_USE_SANITIZER and documents it. Tested via check-cxx (wip to fix the errors). Reviewers: morehouse, #libc! Subscribers: mgorny, cfe-commits, libcxx-commits Tags: #clang, #libc Differential Revision: https://reviews.llvm.org/D78390
2020-04-18 01:15:58 +08:00
elseif (LLVM_USE_SANITIZER STREQUAL "DataFlow")
append("-fsanitize=dataflow" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
Handle LLVM_USE_SANITIZER=Address;Undefined (and the other way around) Summary: Handle LLVM_USE_SANITIZER=Address;Undefined to enable ASan and UBSan If UBSan is compatible with more of the other sanitizers, maybe we should deal with this in a better way where we allow combining UBSan with any of the other sanitizers. Reviewers: samsonov Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D7024 llvm-svn: 228219
2015-02-05 06:33:31 +08:00
elseif (LLVM_USE_SANITIZER STREQUAL "Address;Undefined" OR
LLVM_USE_SANITIZER STREQUAL "Undefined;Address")
append_common_sanitizer_flags()
cmake: Use -fno-sanitize-recover=all - the old spelling is deprecated llvm-svn: 237334
2015-05-14 12:52:57 +08:00
append("-fsanitize=address,undefined -fno-sanitize=vptr,function -fno-sanitize-recover=all"
Handle LLVM_USE_SANITIZER=Address;Undefined (and the other way around) Summary: Handle LLVM_USE_SANITIZER=Address;Undefined to enable ASan and UBSan If UBSan is compatible with more of the other sanitizers, maybe we should deal with this in a better way where we allow combining UBSan with any of the other sanitizers. Reviewers: samsonov Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D7024 llvm-svn: 228219
2015-02-05 06:33:31 +08:00
CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
[cmake] Add support for using the standalone leaks sanitizer with LLVM. This commit causes LLVM_USE_SANITIZER to now accept the "Leaks" option. This will cause cmake to pass in -fsanitize=leak in all of the appropriate places. I am making this change so that I can setup a linux bot that only detects leaks. llvm-svn: 305839
2017-06-21 04:28:07 +08:00
elseif (LLVM_USE_SANITIZER STREQUAL "Leaks")
append_common_sanitizer_flags()
append("-fsanitize=leak" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
Add CMake option LLVM_USE_SANITIZER={Address,Memory,MemoryWithOrigins} to simplify bootstrap of LLVM/Clang under ASan/MSan llvm-svn: 177992
2013-03-26 15:49:46 +08:00
else()
cmake: Error instead of warning and dropping invalid LLVM_USE_SANITIZER Currently, if you call cmake with a typo in an LLVM_USE_SANITIZER value, there's a cmake warning and the build goes on with no sanitizers at all. This isn't a good behaviour, since cmake warnings are fairly easy to miss and the resulting behaviour is that it looks like the build is sanitizer clean. Upgrade these warnings to errors so misconfigurations are more obvious. llvm-svn: 246531
2015-09-01 13:45:07 +08:00
message(FATAL_ERROR "Unsupported value of LLVM_USE_SANITIZER: ${LLVM_USE_SANITIZER}")
Add CMake option LLVM_USE_SANITIZER={Address,Memory,MemoryWithOrigins} to simplify bootstrap of LLVM/Clang under ASan/MSan llvm-svn: 177992
2013-03-26 15:49:46 +08:00
endif()
[cmake] Start adding support for LLVM_USE_SANITIZER=Address on Windows Pass "-fsanitize=address" to the compiler and "-debug" to the linker. llvm-svn: 245070
2015-08-15 00:48:34 +08:00
elseif(MSVC)
if (LLVM_USE_SANITIZER STREQUAL "Address")
append_common_sanitizer_flags()
append("-fsanitize=address" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
else()
cmake: Error instead of warning and dropping invalid LLVM_USE_SANITIZER Currently, if you call cmake with a typo in an LLVM_USE_SANITIZER value, there's a cmake warning and the build goes on with no sanitizers at all. This isn't a good behaviour, since cmake warnings are fairly easy to miss and the resulting behaviour is that it looks like the build is sanitizer clean. Upgrade these warnings to errors so misconfigurations are more obvious. llvm-svn: 246531
2015-09-01 13:45:07 +08:00
message(FATAL_ERROR "This sanitizer not yet supported in the MSVC environment: ${LLVM_USE_SANITIZER}")
[cmake] Start adding support for LLVM_USE_SANITIZER=Address on Windows Pass "-fsanitize=address" to the compiler and "-debug" to the linker. llvm-svn: 245070
2015-08-15 00:48:34 +08:00
endif()
Add CMake option LLVM_USE_SANITIZER={Address,Memory,MemoryWithOrigins} to simplify bootstrap of LLVM/Clang under ASan/MSan llvm-svn: 177992
2013-03-26 15:49:46 +08:00
else()
cmake: Error instead of warning and dropping invalid LLVM_USE_SANITIZER Currently, if you call cmake with a typo in an LLVM_USE_SANITIZER value, there's a cmake warning and the build goes on with no sanitizers at all. This isn't a good behaviour, since cmake warnings are fairly easy to miss and the resulting behaviour is that it looks like the build is sanitizer clean. Upgrade these warnings to errors so misconfigurations are more obvious. llvm-svn: 246531
2015-09-01 13:45:07 +08:00
message(FATAL_ERROR "LLVM_USE_SANITIZER is not supported on this platform.")
Add CMake option LLVM_USE_SANITIZER={Address,Memory,MemoryWithOrigins} to simplify bootstrap of LLVM/Clang under ASan/MSan llvm-svn: 177992
2013-03-26 15:49:46 +08:00
endif()
Enabled -fsanitize-address-use-after-scope for -DLLVM_USE_SANITIZER=Address Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D28823 llvm-svn: 292256
2017-01-18 05:04:23 +08:00
if (LLVM_USE_SANITIZER MATCHES "(Undefined;)?Address(;Undefined)?")
cmake: Only sanitize use-after-scope if the host compiler supports it In r292256, we started adding -fsanitize-use-after-scope when using the address sanitizer, but that flag wasn't always available. This fixes the config to only add the flag if the host compiler supports it. llvm-svn: 292423
2017-01-19 03:01:58 +08:00
add_flag_if_supported("-fsanitize-address-use-after-scope"
FSANITIZE_USE_AFTER_SCOPE_FLAG)
Enabled -fsanitize-address-use-after-scope for -DLLVM_USE_SANITIZER=Address Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D28823 llvm-svn: 292256
2017-01-18 05:04:23 +08:00
endif()
Add cmake flag LLVM_USE_SANITIZE_COVERAGE Summary: When LLVM_USE_SANITIZE_COVERAGE=YES and one of the sanitizers is used -fsanitize-coverage=3 will be added to build flag. This will be used to run a coverage-guided fuzzer on various llvm libraries. Test Plan: n/a Reviewers: rnk Reviewed By: rnk Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D7116 llvm-svn: 227216
2015-01-28 01:59:28 +08:00
if (LLVM_USE_SANITIZE_COVERAGE)
Update LLVM fuzzers to use the libFuzzer bundled with the compiler toolchain Differential Revision: https://reviews.llvm.org/D37041 llvm-svn: 311515
2017-08-23 08:40:58 +08:00
append("-fsanitize=fuzzer-no-link" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
Add cmake flag LLVM_USE_SANITIZE_COVERAGE Summary: When LLVM_USE_SANITIZE_COVERAGE=YES and one of the sanitizers is used -fsanitize-coverage=3 will be added to build flag. This will be used to run a coverage-guided fuzzer on various llvm libraries. Test Plan: n/a Reviewers: rnk Reviewed By: rnk Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D7116 llvm-svn: 227216
2015-01-28 01:59:28 +08:00
endif()
[UBSan] Also use blacklist for 'Address; Undefined' setting It looks like currently the UBSan blacklist is only applied when "Undefined" is selected. This patch updates the cmake file to apply it whenever Undefined is selected (e.g. 'Address; Undefined' ). This allows us to use the workaround added in rL335525 when using AddressSan and UBSan together. Reviewers: eugenis, vitalybuka Reviewed By: eugenis Differential Revision: https://reviews.llvm.org/D49558 llvm-svn: 337539
2018-07-20 18:12:31 +08:00
if (LLVM_USE_SANITIZER MATCHES ".*Undefined.*")
set(BLACKLIST_FILE "${CMAKE_SOURCE_DIR}/utils/sanitizers/ubsan_blacklist.txt")
if (EXISTS "${BLACKLIST_FILE}")
append("-fsanitize-blacklist=${BLACKLIST_FILE}"
CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
endif()
endif()
Add CMake option LLVM_USE_SANITIZER={Address,Memory,MemoryWithOrigins} to simplify bootstrap of LLVM/Clang under ASan/MSan llvm-svn: 177992
2013-03-26 15:49:46 +08:00
endif()
[cmake] Fix LLVM_USE_SPLIT_DWARF Summary: - Add `-gsplit-dwarf` as an option instead of a definition. - Only add that option on compilers supporting dwarf splitting, such as clang and gcc. Reviewers: echristo, pcc Subscribers: mgorny, aprantl, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D75328
2020-02-28 13:01:08 +08:00
# Turn on -gsplit-dwarf if requested in debug builds.
if (LLVM_USE_SPLIT_DWARF AND
((uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG") OR
(uppercase_CMAKE_BUILD_TYPE STREQUAL "RELWITHDEBINFO")))
# Limit to clang and gcc so far. Add compilers supporting this option.
if (CMAKE_CXX_COMPILER_ID MATCHES "Clang" OR
CMAKE_CXX_COMPILER_ID STREQUAL "GNU")
add_compile_options(-gsplit-dwarf)
endif()
Add capability for building with -gsplit-dwarf to the cmake build. In limited testing this seems to work. Caveat emptor. llvm-svn: 187452
2013-07-31 05:44:10 +08:00
endif()
Fix evaluation of LLVM_DEFINITIONS CMake variable LLVM_DEFINITIONS collects preprocessor definitions provided for host compiler that builds llvm components. A function add_llvm_definitions was introduced in AddLLVMDefinitions.cmake to keep track of these definitions and was intended to be a replacement for CMake command add_definitions. Actually in many cases add_definitions is still used and the content of LLVM_DEFINITIONS is not actual now. On the other hand the current version of CMake allows getting set of definitions in a more convenient way. This fix implements evaluation of the variable by reading corresponding cmake property. Differential Revision: https://reviews.llvm.org/D31125 llvm-svn: 298336
2017-03-21 12:03:24 +08:00
add_definitions( -D__STDC_CONSTANT_MACROS )
add_definitions( -D__STDC_FORMAT_MACROS )
add_definitions( -D__STDC_LIMIT_MACROS )
Add colored diagnostics when building LLVM with cmake + ninja + clang When invoked from Ninja, clang does not detect that it can use colors : see https://github.com/martine/ninja/issues/174 llvm-svn: 182878
2013-05-30 04:41:35 +08:00
Enable colored diagnostics in ninja builds when building with gcc 4.9+. GCC has supported -fdiagnostics-color since 4.9. https://reviews.llvm.org/D47083 llvm-svn: 332793
2018-05-19 10:36:27 +08:00
# clang and gcc don't default-print colored diagnostics when invoked from Ninja.
Revert "Cmake: add compiler option in a more idiomatic way" This reverts commit 183995. It broke the bots: http://bb.pgr.jp/builders/cmake-clang-x86_64-linux/builds/9730/steps/build_clang/logs/stdio llvm-svn: 183997
2013-06-15 03:41:05 +08:00
if (UNIX AND
Enable colored diagnostics in ninja builds when building with gcc 4.9+. GCC has supported -fdiagnostics-color since 4.9. https://reviews.llvm.org/D47083 llvm-svn: 332793
2018-05-19 10:36:27 +08:00
CMAKE_GENERATOR STREQUAL "Ninja" AND
(CMAKE_CXX_COMPILER_ID MATCHES "Clang" OR
(CMAKE_CXX_COMPILER_ID STREQUAL "GNU" AND
NOT (CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.9))))
append("-fdiagnostics-color" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
Add colored diagnostics when building LLVM with cmake + ninja + clang When invoked from Ninja, clang does not detect that it can use colors : see https://github.com/martine/ninja/issues/174 llvm-svn: 182878
2013-05-30 04:41:35 +08:00
endif()
[CMake] Move -ffunction-data-sections stuff to HandleLLVMOptions. With this tweaks, also unittests are compiled with -ffunction-sections. It's hard to control contextual CMAKE_CXX_FLAGS. We should get rid of twiddling it as possible. llvm-svn: 200299
2014-01-28 17:43:55 +08:00
Add -Wl,-color-diagnostics if a linker supports the option. Differential Revision: https://reviews.llvm.org/D28046 llvm-svn: 291719
2017-01-12 06:55:35 +08:00
# lld doesn't print colored diagnostics when invoked from Ninja
Revert "build: reserve `--color-diagnostics` for lld" This reverts SVN r330158. Seems that there was a change to linker flags handling in SVN r316972. That would alter the behaviour to correct the linker flag handling in CMake (requiring CMake 3.4.3+). Since that is already the minimum version required for LLVM, hard coding the knowledge of the linker is not required, which is a strictly better solution. llvm-svn: 330161
2018-04-17 05:57:10 +08:00
if (UNIX AND CMAKE_GENERATOR STREQUAL "Ninja")
Add -Wl,-color-diagnostics if a linker supports the option. Differential Revision: https://reviews.llvm.org/D28046 llvm-svn: 291719
2017-01-12 06:55:35 +08:00
include(CheckLinkerFlag)
Use --color-diagnostics instead of -color-diagnostics. Solaris ld interprets -color-diagnostics as a -c option, so it is better to use --color-diagnostics instead. lld accepts both. Differential Revision: https://reviews.llvm.org/D35327 llvm-svn: 307850
2017-07-13 05:37:02 +08:00
check_linker_flag("-Wl,--color-diagnostics" LINKER_SUPPORTS_COLOR_DIAGNOSTICS)
append_if(LINKER_SUPPORTS_COLOR_DIAGNOSTICS "-Wl,--color-diagnostics"
Add -Wl,-color-diagnostics if a linker supports the option. Differential Revision: https://reviews.llvm.org/D28046 llvm-svn: 291719
2017-01-12 06:55:35 +08:00
CMAKE_EXE_LINKER_FLAGS CMAKE_MODULE_LINKER_FLAGS CMAKE_SHARED_LINKER_FLAGS)
endif()
[CMake] Move -ffunction-data-sections stuff to HandleLLVMOptions. With this tweaks, also unittests are compiled with -ffunction-sections. It's hard to control contextual CMAKE_CXX_FLAGS. We should get rid of twiddling it as possible. llvm-svn: 200299
2014-01-28 17:43:55 +08:00
# Add flags for add_dead_strip().
# FIXME: With MSVS, consider compiling with /Gy and linking with /OPT:REF?
# But MinSizeRel seems to add that automatically, so maybe disable these
Revert "[NFC] Rename LLVM_NO_DEAD_STRIP" This reverts commit 11c2a85db8849db1a5907e80d9966592248ef825.
2019-10-31 02:56:20 +08:00
# flags instead if LLVM_NO_DEAD_STRIP is set.
[CMake] Move -ffunction-data-sections stuff to HandleLLVMOptions. With this tweaks, also unittests are compiled with -ffunction-sections. It's hard to control contextual CMAKE_CXX_FLAGS. We should get rid of twiddling it as possible. llvm-svn: 200299
2014-01-28 17:43:55 +08:00
if(NOT CYGWIN AND NOT WIN32)
Don't use -ffunction-sections -fdata-sections on debug builds. Unfortunately, on ELF there is not used attribute on the .o files, so there is no easy way to keep the dump function alive. If we are not gcing, we may as well produce non gcable files and avoid the cost. Linking a debug clang now takes 18.856225992 seconds, before it took 21.206897447. I will try avoiding --gc-sections -O3 on a followup patch. llvm-svn: 234159
2015-04-06 22:34:43 +08:00
if(NOT ${CMAKE_SYSTEM_NAME} MATCHES "Darwin" AND
NOT uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG")
[CMake] Revert r200695 and fix the problem with missing -fno-function-sections in a different way. llvm-svn: 200745
2014-02-04 16:15:46 +08:00
check_c_compiler_flag("-Werror -fno-function-sections" C_SUPPORTS_FNO_FUNCTION_SECTIONS)
if (C_SUPPORTS_FNO_FUNCTION_SECTIONS)
[CMake] Enable -qfuncsect when building with IBM XL Summary: The IBM XL compiler uses `-qfuncsect` for `-ffunction-sections`. The comment about sanitizers and `-f[no-]function-sections` is corrected also, as it is pertinent to this patch. The sanitizer-related use of `-fno-function-sections` is associated with powerpc64le, a target for which there is an IBM XL compiler, so that use is updated in this patch to apply `-qnofuncsect` in case a build using the XL compiler is viable on that platform. This patch has been verified with the XL compiler on AIX only. Reviewers: daltenty, stevewan Reviewed By: daltenty Subscribers: mgorny, steven.zhang, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D72335
2020-01-15 23:42:12 +08:00
# Don't add -ffunction-sections if it can't be disabled with -fno-function-sections.
[CMake] Revert r200695 and fix the problem with missing -fno-function-sections in a different way. llvm-svn: 200745
2014-02-04 16:15:46 +08:00
# Doing so will break sanitizers.
CMake: fix compiler feature detection add_flag_if_supported() and add_flag_or_print_warning() were effectively no-ops, just returning the value of the first result (usually '-fno-omit-frame-pointer') for all subsequent checks for different flags. Due to the way CMake caches feature detection results, we need to provide symbolic variable names which will persist the cached results. This commit fixes feature detection using these two macros. The feature checks now run and get stored correctly, and the correct output can be observed in configure logs: -- Performing Test C_SUPPORTS_FPIC -- Performing Test C_SUPPORTS_FPIC - Success -- Performing Test CXX_SUPPORTS_FPIC -- Performing Test CXX_SUPPORTS_FPIC - Success llvm-svn: 212586
2014-07-09 11:38:19 +08:00
add_flag_if_supported("-ffunction-sections" FFUNCTION_SECTIONS)
[CMake] Enable -qfuncsect when building with IBM XL Summary: The IBM XL compiler uses `-qfuncsect` for `-ffunction-sections`. The comment about sanitizers and `-f[no-]function-sections` is corrected also, as it is pertinent to this patch. The sanitizer-related use of `-fno-function-sections` is associated with powerpc64le, a target for which there is an IBM XL compiler, so that use is updated in this patch to apply `-qnofuncsect` in case a build using the XL compiler is viable on that platform. This patch has been verified with the XL compiler on AIX only. Reviewers: daltenty, stevewan Reviewed By: daltenty Subscribers: mgorny, steven.zhang, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D72335
2020-01-15 23:42:12 +08:00
elseif (CMAKE_CXX_COMPILER_ID MATCHES "XL")
append("-qfuncsect" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
Don't use -ffunction-sections if -fno-function-sections is not supported in the compiler. This will disable -ffunction-sections in older versions of Clang where it breaks build of sanitizer runtime library. llvm-svn: 200695
2014-02-03 21:57:09 +08:00
endif()
CMake: fix compiler feature detection add_flag_if_supported() and add_flag_or_print_warning() were effectively no-ops, just returning the value of the first result (usually '-fno-omit-frame-pointer') for all subsequent checks for different flags. Due to the way CMake caches feature detection results, we need to provide symbolic variable names which will persist the cached results. This commit fixes feature detection using these two macros. The feature checks now run and get stored correctly, and the correct output can be observed in configure logs: -- Performing Test C_SUPPORTS_FPIC -- Performing Test C_SUPPORTS_FPIC - Success -- Performing Test CXX_SUPPORTS_FPIC -- Performing Test CXX_SUPPORTS_FPIC - Success llvm-svn: 212586
2014-07-09 11:38:19 +08:00
add_flag_if_supported("-fdata-sections" FDATA_SECTIONS)
[CMake] Move -ffunction-data-sections stuff to HandleLLVMOptions. With this tweaks, also unittests are compiled with -ffunction-sections. It's hard to control contextual CMAKE_CXX_FLAGS. We should get rid of twiddling it as possible. llvm-svn: 200299
2014-01-28 17:43:55 +08:00
endif()
[windows] Add /Gw to compiler flags This is like -fdata-sections, and it's not part of /O2 by default for some reason. In the cmake build, reduces the size of clang.exe from 70,358,016 bytes to 69,982,720 bytes. clang-format.exe goes from 3,703,296 bytes to 3,331,072 bytes. Differential Revision: https://reviews.llvm.org/D74573
2020-02-15 04:15:00 +08:00
elseif(MSVC)
if( NOT uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG" )
append("/Gw" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
endif()
[CMake] Move -ffunction-data-sections stuff to HandleLLVMOptions. With this tweaks, also unittests are compiled with -ffunction-sections. It's hard to control contextual CMAKE_CXX_FLAGS. We should get rid of twiddling it as possible. llvm-svn: 200299
2014-01-28 17:43:55 +08:00
endif()
[CMake] Enhance llvm_update_compile_flags(name sources) to handle LLVM_REQUIRES_EH and LLVM_REQUIRES_RTTI. LLVM_REQUIRES_EH implies LLVM_REQUIRES_RTTI. It is as same behavior as Makefile.rule's. llvm/examples/ExceptionDemo is affected. (It was built with -fno-rtti.) For MSVC, Remove flags like "/EHsc /GR" in HandleLLVMOptions, or CL.EXE complains with flags like "/GR /GR-". llvm_update_compile_flags() updates source file property if the target contains *.c. COMPILE_FLAGS in target properties affects both C++ and C! LLVM_NO_RTTI is deprecated. It was introduced by me and was my mistake. llvm-svn: 200301
2014-01-28 17:44:06 +08:00
if(MSVC)
# Remove flags here, for exceptions and RTTI.
HandleLLVMOptions.cmake: Typo, s/proerty/property/ llvm-svn: 200556
2014-02-01 01:32:36 +08:00
# Each target property or source property should be responsible to control
# them.
[CMake] Enhance llvm_update_compile_flags(name sources) to handle LLVM_REQUIRES_EH and LLVM_REQUIRES_RTTI. LLVM_REQUIRES_EH implies LLVM_REQUIRES_RTTI. It is as same behavior as Makefile.rule's. llvm/examples/ExceptionDemo is affected. (It was built with -fno-rtti.) For MSVC, Remove flags like "/EHsc /GR" in HandleLLVMOptions, or CL.EXE complains with flags like "/GR /GR-". llvm_update_compile_flags() updates source file property if the target contains *.c. COMPILE_FLAGS in target properties affects both C++ and C! LLVM_NO_RTTI is deprecated. It was introduced by me and was my mistake. llvm-svn: 200301
2014-01-28 17:44:06 +08:00
# CL.EXE complains to override flags like "/GR /GR-".
string(REGEX REPLACE "(^| ) */EH[-cs]+ *( |$)" "\\1 \\2" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
string(REGEX REPLACE "(^| ) */GR-? *( |$)" "\\1 \\2" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
endif()
[CMake] Introduce LLVM_ENABLE_PLUGINS as an internal option. BUILD_SHARED_LIBS may not control enable/disable plugins. FIXME: Make this configurable. FIXME: "ENABLE_SHARED" doesn't make sense, since it is used just for plugins. We may rename it. I introduced config.enable_shared in r120273. llvm-svn: 212315
2014-07-04 12:45:40 +08:00
Added LLVM_ENABLE_RTTI and LLVM_ENABLE_EH options that allow RTTI and EH to globally be controlled. Individual targets (e.g. ExceptionDemo) can still override this by using LLVM_REQUIRE_RTTI and LLVM_REQUIRE_EH if they need to be compiled with RTTI or exception handling respectively. llvm-svn: 213663
2014-07-22 23:41:18 +08:00
# Provide public options to globally control RTTI and EH
option(LLVM_ENABLE_EH "Enable Exception handling" OFF)
option(LLVM_ENABLE_RTTI "Enable run time type information" OFF)
if(LLVM_ENABLE_EH AND NOT LLVM_ENABLE_RTTI)
message(FATAL_ERROR "Exception handling requires RTTI. You must set LLVM_ENABLE_RTTI to ON")
endif()
[Cmake] Add an option to build LLVM using the experimental new pass manager Add LLVM_USE_NEWPM to build LLVM using the experimental new pass manager. Differential Revision: http://reviews.llvm.org/D57068 llvm-svn: 353550
2019-02-09 03:31:03 +08:00
option(LLVM_USE_NEWPM "Build LLVM using the experimental new pass manager" Off)
mark_as_advanced(LLVM_USE_NEWPM)
if (LLVM_USE_NEWPM)
append("-fexperimental-new-pass-manager"
CMAKE_CXX_FLAGS
CMAKE_C_FLAGS
CMAKE_EXE_LINKER_FLAGS
CMAKE_SHARED_LINKER_FLAGS)
endif()
[cmake] Allow LLVM_BUILD_INSTRUMENTED to be set to IR or Frontend - This deprecates LLVM_ENABLE_IR_PGO but keeps it around for now. - Errors out when LLVM_BUILD_INSTRUMENTED and LLVM_BUILD_INSTRUMENTED_COVERAGE are both set. Motivated by bogner's post-commit review of r313770. llvm-svn: 317725
2017-11-09 05:26:40 +08:00
option(LLVM_ENABLE_IR_PGO "Build LLVM and tools with IR PGO instrumentation (deprecated)" Off)
[cmake] Add an option to build llvm with IR PGO This adds an LLVM_ENABLE_IR_PGO option to enable building llvm and its tools with IR PGO instrumentation. Usage: -DLLVM_BUILD_INSTRUMENTED=On -DLLVM_ENABLE_IR_PGO=On (both options must be enabled) Differential Revision: https://reviews.llvm.org/D38066 llvm-svn: 313770
2017-09-21 01:16:01 +08:00
mark_as_advanced(LLVM_ENABLE_IR_PGO)
[cmake] Allow LLVM_BUILD_INSTRUMENTED to be set to IR or Frontend - This deprecates LLVM_ENABLE_IR_PGO but keeps it around for now. - Errors out when LLVM_BUILD_INSTRUMENTED and LLVM_BUILD_INSTRUMENTED_COVERAGE are both set. Motivated by bogner's post-commit review of r313770. llvm-svn: 317725
2017-11-09 05:26:40 +08:00
set(LLVM_BUILD_INSTRUMENTED OFF CACHE STRING "Build LLVM and tools with PGO instrumentation. May be specified as IR or Frontend")
[CMake] Add LLVM_BUILD_INSTRUMENTED option to enable building with -fprofile-instr-generate This is the first step in supporting PGO data generation via CMake. I've marked the option as advanced and experimental until it is fleshed out further. llvm-svn: 255298
2015-12-11 05:19:07 +08:00
mark_as_advanced(LLVM_BUILD_INSTRUMENTED)
[cmake] Allow LLVM_BUILD_INSTRUMENTED to be set to IR or Frontend - This deprecates LLVM_ENABLE_IR_PGO but keeps it around for now. - Errors out when LLVM_BUILD_INSTRUMENTED and LLVM_BUILD_INSTRUMENTED_COVERAGE are both set. Motivated by bogner's post-commit review of r313770. llvm-svn: 317725
2017-11-09 05:26:40 +08:00
string(TOUPPER "${LLVM_BUILD_INSTRUMENTED}" uppercase_LLVM_BUILD_INSTRUMENTED)
[cmake] Add an option to build llvm with IR PGO This adds an LLVM_ENABLE_IR_PGO option to enable building llvm and its tools with IR PGO instrumentation. Usage: -DLLVM_BUILD_INSTRUMENTED=On -DLLVM_ENABLE_IR_PGO=On (both options must be enabled) Differential Revision: https://reviews.llvm.org/D38066 llvm-svn: 313770
2017-09-21 01:16:01 +08:00
if (LLVM_BUILD_INSTRUMENTED)
[cmake] Allow LLVM_BUILD_INSTRUMENTED to be set to IR or Frontend - This deprecates LLVM_ENABLE_IR_PGO but keeps it around for now. - Errors out when LLVM_BUILD_INSTRUMENTED and LLVM_BUILD_INSTRUMENTED_COVERAGE are both set. Motivated by bogner's post-commit review of r313770. llvm-svn: 317725
2017-11-09 05:26:40 +08:00
if (LLVM_ENABLE_IR_PGO OR uppercase_LLVM_BUILD_INSTRUMENTED STREQUAL "IR")
[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 17:43:13 +08:00
append("-fprofile-generate=\"${LLVM_PROFILE_DATA_DIR}\""
[cmake] Add an option to build llvm with IR PGO This adds an LLVM_ENABLE_IR_PGO option to enable building llvm and its tools with IR PGO instrumentation. Usage: -DLLVM_BUILD_INSTRUMENTED=On -DLLVM_ENABLE_IR_PGO=On (both options must be enabled) Differential Revision: https://reviews.llvm.org/D38066 llvm-svn: 313770
2017-09-21 01:16:01 +08:00
CMAKE_CXX_FLAGS
[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 17:43:13 +08:00
CMAKE_C_FLAGS)
if(NOT LINKER_IS_LLD_LINK)
append("-fprofile-generate=\"${LLVM_PROFILE_DATA_DIR}\""
CMAKE_EXE_LINKER_FLAGS
CMAKE_SHARED_LINKER_FLAGS)
endif()
[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-07 03:31:37 +08:00
elseif(uppercase_LLVM_BUILD_INSTRUMENTED STREQUAL "CSIR")
[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 17:43:13 +08:00
append("-fcs-profile-generate=\"${LLVM_CSPROFILE_DATA_DIR}\""
[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-07 03:31:37 +08:00
CMAKE_CXX_FLAGS
[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 17:43:13 +08:00
CMAKE_C_FLAGS)
if(NOT LINKER_IS_LLD_LINK)
append("-fcs-profile-generate=\"${LLVM_CSPROFILE_DATA_DIR}\""
CMAKE_EXE_LINKER_FLAGS
CMAKE_SHARED_LINKER_FLAGS)
endif()
[cmake] Add an option to build llvm with IR PGO This adds an LLVM_ENABLE_IR_PGO option to enable building llvm and its tools with IR PGO instrumentation. Usage: -DLLVM_BUILD_INSTRUMENTED=On -DLLVM_ENABLE_IR_PGO=On (both options must be enabled) Differential Revision: https://reviews.llvm.org/D38066 llvm-svn: 313770
2017-09-21 01:16:01 +08:00
else()
[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 17:43:13 +08:00
append("-fprofile-instr-generate=\"${LLVM_PROFILE_FILE_PATTERN}\""
[cmake] Add an option to build llvm with IR PGO This adds an LLVM_ENABLE_IR_PGO option to enable building llvm and its tools with IR PGO instrumentation. Usage: -DLLVM_BUILD_INSTRUMENTED=On -DLLVM_ENABLE_IR_PGO=On (both options must be enabled) Differential Revision: https://reviews.llvm.org/D38066 llvm-svn: 313770
2017-09-21 01:16:01 +08:00
CMAKE_CXX_FLAGS
[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 17:43:13 +08:00
CMAKE_C_FLAGS)
if(NOT LINKER_IS_LLD_LINK)
append("-fprofile-instr-generate=\"${LLVM_PROFILE_FILE_PATTERN}\""
CMAKE_EXE_LINKER_FLAGS
CMAKE_SHARED_LINKER_FLAGS)
endif()
[cmake] Add an option to build llvm with IR PGO This adds an LLVM_ENABLE_IR_PGO option to enable building llvm and its tools with IR PGO instrumentation. Usage: -DLLVM_BUILD_INSTRUMENTED=On -DLLVM_ENABLE_IR_PGO=On (both options must be enabled) Differential Revision: https://reviews.llvm.org/D38066 llvm-svn: 313770
2017-09-21 01:16:01 +08: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-14 07:33:48 +08:00
[Windows] Autolink with basenames and add libdir to libpath Prior to this change, for a few compiler-rt libraries such as ubsan and the profile library, Clang would embed "-defaultlib:path/to/rt-arch.lib" into the .drective section of every object compiled with -finstr-profile-generate or -fsanitize=ubsan as appropriate. These paths assume that the link step will run from the same working directory as the compile step. There is also evidence that sometimes the paths become absolute, such as when clang is run from a different drive letter from the current working directory. This is fragile, and I'd like to get away from having paths embedded in the object if possible. Long ago it was suggested that we use this for ASan, and apparently I felt the same way back then: https://reviews.llvm.org/D4428#56536 This is also consistent with how all other autolinking usage works for PS4, Mac, and Windows: they all use basenames, not paths. To keep things working for people using the standard GCC driver workflow, the driver now adds the resource directory to the linker library search path when it calls the linker. This is enough to make check-ubsan pass, and seems like a generally good thing. Users that invoke the linker directly (most clang-cl users) will have to add clang's resource library directory to their linker search path in their build system. I'm not sure where I can document this. Ideally I'd also do it in the MSBuild files, but I can't figure out where they go. I'd like to start with this for now. Reviewed By: hans Differential Revision: https://reviews.llvm.org/D65543
2019-08-01 05:52:00 +08:00
# When using clang-cl with an instrumentation-based tool, add clang's library
# resource directory to the library search path. Because cmake invokes the
# linker directly, it isn't sufficient to pass -fsanitize=* to the linker.
if (CLANG_CL AND (LLVM_BUILD_INSTRUMENTED OR LLVM_USE_SANITIZER))
execute_process(
COMMAND ${CMAKE_CXX_COMPILER} /clang:-print-resource-dir
OUTPUT_VARIABLE clang_resource_dir
ERROR_VARIABLE clang_cl_stderr
OUTPUT_STRIP_TRAILING_WHITESPACE
ERROR_STRIP_TRAILING_WHITESPACE
RESULT_VARIABLE clang_cl_exit_code)
if (NOT "${clang_cl_exit_code}" STREQUAL "0")
message(FATAL_ERROR
"Unable to invoke clang-cl to find resource dir: ${clang_cl_stderr}")
endif()
file(TO_CMAKE_PATH "${clang_resource_dir}" clang_resource_dir)
append("/libpath:${clang_resource_dir}/lib/windows"
CMAKE_EXE_LINKER_FLAGS
[cmake][Windows] Add libpath to CMAKE_MODULE_LINKER_FLAGS too Followup to b8000c0ce845, the library path needs to go in CMAKE_MODULE_LINKER_FLAGS too, for the sake of a few files like LLVMHello.dll. Reviewed By: hans Differential Revision: https://reviews.llvm.org/D82888
2020-07-01 22:17:00 +08:00
CMAKE_MODULE_LINKER_FLAGS
[Windows] Autolink with basenames and add libdir to libpath Prior to this change, for a few compiler-rt libraries such as ubsan and the profile library, Clang would embed "-defaultlib:path/to/rt-arch.lib" into the .drective section of every object compiled with -finstr-profile-generate or -fsanitize=ubsan as appropriate. These paths assume that the link step will run from the same working directory as the compile step. There is also evidence that sometimes the paths become absolute, such as when clang is run from a different drive letter from the current working directory. This is fragile, and I'd like to get away from having paths embedded in the object if possible. Long ago it was suggested that we use this for ASan, and apparently I felt the same way back then: https://reviews.llvm.org/D4428#56536 This is also consistent with how all other autolinking usage works for PS4, Mac, and Windows: they all use basenames, not paths. To keep things working for people using the standard GCC driver workflow, the driver now adds the resource directory to the linker library search path when it calls the linker. This is enough to make check-ubsan pass, and seems like a generally good thing. Users that invoke the linker directly (most clang-cl users) will have to add clang's resource library directory to their linker search path in their build system. I'm not sure where I can document this. Ideally I'd also do it in the MSBuild files, but I can't figure out where they go. I'd like to start with this for now. Reviewed By: hans Differential Revision: https://reviews.llvm.org/D65543
2019-08-01 05:52:00 +08:00
CMAKE_SHARED_LINKER_FLAGS)
endif()
[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-07 03:31:37 +08:00
if(LLVM_PROFDATA_FILE AND EXISTS ${LLVM_PROFDATA_FILE})
[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 17:43:13 +08:00
if ("${CMAKE_CXX_COMPILER_ID}" MATCHES "Clang" )
append("-fprofile-instr-use=\"${LLVM_PROFDATA_FILE}\""
CMAKE_CXX_FLAGS
CMAKE_C_FLAGS)
if(NOT LINKER_IS_LLD_LINK)
append("-fprofile-instr-use=\"${LLVM_PROFDATA_FILE}\""
CMAKE_EXE_LINKER_FLAGS
CMAKE_SHARED_LINKER_FLAGS)
endif()
else()
message(FATAL_ERROR "LLVM_PROFDATA_FILE can only be specified when compiling with clang")
endif()
[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-07 03:31:37 +08:00
endif()
[cmake] Unmark LLVM_BUILD_INSTRUMENTED_COVERAGE as experimental The coverage bot has been stable for a while: http://lab.llvm.org:8080/coverage/coverage-reports/index.html llvm-svn: 313769
2017-09-21 01:16:00 +08:00
option(LLVM_BUILD_INSTRUMENTED_COVERAGE "Build LLVM and tools with Code Coverage instrumentation" Off)
Add support for collating profiles for use with code coverage Differential Revision: http://reviews.llvm.org/D20993 llvm-svn: 272599
2016-06-14 07:33:48 +08:00
mark_as_advanced(LLVM_BUILD_INSTRUMENTED_COVERAGE)
Use double quotes for LDFLAGS in -DLLVM_BUILD_INSTRUMENTED_COVERAGE Mimics the changes in r372209 to handle the change of quotes in r372226. Probably isn't sufficient for windows, but unbreaks the cmake flag at least. llvm-svn: 372791
2019-09-25 07:56:22 +08:00
append_if(LLVM_BUILD_INSTRUMENTED_COVERAGE "-fprofile-instr-generate=\"${LLVM_PROFILE_FILE_PATTERN}\" -fcoverage-mapping"
[CMake] Add LLVM_BUILD_INSTRUMENTED option to enable building with -fprofile-instr-generate This is the first step in supporting PGO data generation via CMake. I've marked the option as advanced and experimental until it is fleshed out further. llvm-svn: 255298
2015-12-11 05:19:07 +08:00
CMAKE_CXX_FLAGS
CMAKE_C_FLAGS
CMAKE_EXE_LINKER_FLAGS
CMAKE_SHARED_LINKER_FLAGS)
[cmake] Allow LLVM_BUILD_INSTRUMENTED to be set to IR or Frontend - This deprecates LLVM_ENABLE_IR_PGO but keeps it around for now. - Errors out when LLVM_BUILD_INSTRUMENTED and LLVM_BUILD_INSTRUMENTED_COVERAGE are both set. Motivated by bogner's post-commit review of r313770. llvm-svn: 317725
2017-11-09 05:26:40 +08:00
if (LLVM_BUILD_INSTRUMENTED AND LLVM_BUILD_INSTRUMENTED_COVERAGE)
message(FATAL_ERROR "LLVM_BUILD_INSTRUMENTED and LLVM_BUILD_INSTRUMENTED_COVERAGE cannot both be specified")
endif()
[CMake] Properly handle the LTO cache arguments for MinGW We want to make sure that LINKER_IS_LLD_LINK is properly set - in this case it shouldn't be set when building for MinGW. Then we want to make the test for it correct and finally include the option to build with thinlto cache since the MinGW driver now supports that. Differential Revision: https://reviews.llvm.org/D80493
2020-05-25 15:28:17 +08:00
if(LLVM_ENABLE_LTO AND LLVM_ON_WIN32 AND NOT LINKER_IS_LLD_LINK AND NOT MINGW)
enable building with LTO on Windows using clang-cl and lld Summary: With clang-cl gaining support for link-time optimization, we can now enable builds using LTO when using clang-cl and lld on Windows. To do this, we must not pass the -flto flag to the linker; lld-link does not understand it, but will perform LTO automatically when it encounters bitcode files. We also don't pass /Brepro when using LTO - the compiler doesn't generate object files for LTO, so passing the flag would only result in a warning about it being unused. Reviewers: rnk, ruiu, hans Reviewed By: hans Subscribers: mgorny, mehdi_amini, llvm-commits Differential Revision: https://reviews.llvm.org/D30240 llvm-svn: 296658
2017-03-02 03:22:18 +08:00
message(FATAL_ERROR "When compiling for Windows, LLVM_ENABLE_LTO requires using lld as the linker (point CMAKE_LINKER at lld-link.exe)")
endif()
cmake: Accept "thin" or "full" as arguments to -DLLVM_ENABLE_LTO Mehdi suggested in a review of r259766 that it's also useful to easily set the type of LTO. Augment the cmake variable to support that. llvm-svn: 260143
2016-02-09 05:01:24 +08:00
if(uppercase_LLVM_ENABLE_LTO STREQUAL "THIN")
enable building with LTO on Windows using clang-cl and lld Summary: With clang-cl gaining support for link-time optimization, we can now enable builds using LTO when using clang-cl and lld on Windows. To do this, we must not pass the -flto flag to the linker; lld-link does not understand it, but will perform LTO automatically when it encounters bitcode files. We also don't pass /Brepro when using LTO - the compiler doesn't generate object files for LTO, so passing the flag would only result in a warning about it being unused. Reviewers: rnk, ruiu, hans Reviewed By: hans Subscribers: mgorny, mehdi_amini, llvm-commits Differential Revision: https://reviews.llvm.org/D30240 llvm-svn: 296658
2017-03-02 03:22:18 +08:00
append("-flto=thin" CMAKE_CXX_FLAGS CMAKE_C_FLAGS)
if(NOT LINKER_IS_LLD_LINK)
append("-flto=thin" CMAKE_EXE_LINKER_FLAGS CMAKE_SHARED_LINKER_FLAGS)
endif()
Re-apply r296730, "cmake: Configure the ThinLTO cache directory when using ELF lld or gold." All known cache-related bugs observed when self hosting have been fixed (r296907 and r297853). llvm-svn: 297854
2017-03-16 00:28:43 +08:00
# If the linker supports it, enable the lto cache. This improves initial build
# time a little since we re-link a lot of the same objects, and significantly
# improves incremental build time.
# FIXME: We should move all this logic into the clang driver.
if(APPLE)
append("-Wl,-cache_path_lto,${PROJECT_BINARY_DIR}/lto.cache"
CMAKE_EXE_LINKER_FLAGS CMAKE_SHARED_LINKER_FLAGS)
[CMake] Properly handle the LTO cache arguments for MinGW We want to make sure that LINKER_IS_LLD_LINK is properly set - in this case it shouldn't be set when building for MinGW. Then we want to make the test for it correct and finally include the option to build with thinlto cache since the MinGW driver now supports that. Differential Revision: https://reviews.llvm.org/D80493
2020-05-25 15:28:17 +08:00
elseif((UNIX OR MINGW) AND LLVM_USE_LINKER STREQUAL "lld")
Re-apply r296730, "cmake: Configure the ThinLTO cache directory when using ELF lld or gold." All known cache-related bugs observed when self hosting have been fixed (r296907 and r297853). llvm-svn: 297854
2017-03-16 00:28:43 +08:00
append("-Wl,--thinlto-cache-dir=${PROJECT_BINARY_DIR}/lto.cache"
CMAKE_EXE_LINKER_FLAGS CMAKE_SHARED_LINKER_FLAGS)
elseif(LLVM_USE_LINKER STREQUAL "gold")
append("-Wl,--plugin-opt,cache-dir=${PROJECT_BINARY_DIR}/lto.cache"
CMAKE_EXE_LINKER_FLAGS CMAKE_SHARED_LINKER_FLAGS)
[cmake] Enable thin lto cache when building with lld-link This was enabled for other platforms. Added option for Windows/lld-link. Differential Revision: https://reviews.llvm.org/D69941
2019-11-08 18:46:24 +08:00
elseif(LINKER_IS_LLD_LINK)
append("/lldltocache:${PROJECT_BINARY_DIR}/lto.cache"
CMAKE_EXE_LINKER_FLAGS CMAKE_SHARED_LINKER_FLAGS)
Re-apply r296730, "cmake: Configure the ThinLTO cache directory when using ELF lld or gold." All known cache-related bugs observed when self hosting have been fixed (r296907 and r297853). llvm-svn: 297854
2017-03-16 00:28:43 +08:00
endif()
cmake: Accept "thin" or "full" as arguments to -DLLVM_ENABLE_LTO Mehdi suggested in a review of r259766 that it's also useful to easily set the type of LTO. Augment the cmake variable to support that. llvm-svn: 260143
2016-02-09 05:01:24 +08:00
elseif(uppercase_LLVM_ENABLE_LTO STREQUAL "FULL")
enable building with LTO on Windows using clang-cl and lld Summary: With clang-cl gaining support for link-time optimization, we can now enable builds using LTO when using clang-cl and lld on Windows. To do this, we must not pass the -flto flag to the linker; lld-link does not understand it, but will perform LTO automatically when it encounters bitcode files. We also don't pass /Brepro when using LTO - the compiler doesn't generate object files for LTO, so passing the flag would only result in a warning about it being unused. Reviewers: rnk, ruiu, hans Reviewed By: hans Subscribers: mgorny, mehdi_amini, llvm-commits Differential Revision: https://reviews.llvm.org/D30240 llvm-svn: 296658
2017-03-02 03:22:18 +08:00
append("-flto=full" CMAKE_CXX_FLAGS CMAKE_C_FLAGS)
if(NOT LINKER_IS_LLD_LINK)
append("-flto=full" CMAKE_EXE_LINKER_FLAGS CMAKE_SHARED_LINKER_FLAGS)
endif()
cmake: Accept "thin" or "full" as arguments to -DLLVM_ENABLE_LTO Mehdi suggested in a review of r259766 that it's also useful to easily set the type of LTO. Augment the cmake variable to support that. llvm-svn: 260143
2016-02-09 05:01:24 +08:00
elseif(LLVM_ENABLE_LTO)
enable building with LTO on Windows using clang-cl and lld Summary: With clang-cl gaining support for link-time optimization, we can now enable builds using LTO when using clang-cl and lld on Windows. To do this, we must not pass the -flto flag to the linker; lld-link does not understand it, but will perform LTO automatically when it encounters bitcode files. We also don't pass /Brepro when using LTO - the compiler doesn't generate object files for LTO, so passing the flag would only result in a warning about it being unused. Reviewers: rnk, ruiu, hans Reviewed By: hans Subscribers: mgorny, mehdi_amini, llvm-commits Differential Revision: https://reviews.llvm.org/D30240 llvm-svn: 296658
2017-03-02 03:22:18 +08:00
append("-flto" CMAKE_CXX_FLAGS CMAKE_C_FLAGS)
if(NOT LINKER_IS_LLD_LINK)
append("-flto" CMAKE_EXE_LINKER_FLAGS CMAKE_SHARED_LINKER_FLAGS)
endif()
cmake: Accept "thin" or "full" as arguments to -DLLVM_ENABLE_LTO Mehdi suggested in a review of r259766 that it's also useful to easily set the type of LTO. Augment the cmake variable to support that. llvm-svn: 260143
2016-02-09 05:01:24 +08:00
endif()
cmake: Add a flag to enable LTO This adds -DLLVM_ENABLE_LTO, rather than forcing people to manually add -flto to the various _FLAGS variables. llvm-svn: 259766
2016-02-04 15:28:30 +08:00
[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-09 01:45:44 +08:00
# Set an AIX default for LLVM_EXPORT_SYMBOLS_FOR_PLUGINS based on whether we are
# doing dynamic linking (see below).
set(LLVM_EXPORT_SYMBOLS_FOR_PLUGINS_AIX_default OFF)
if (NOT (BUILD_SHARED_LIBS OR LLVM_LINK_LLVM_DYLIB))
set(LLVM_EXPORT_SYMBOLS_FOR_PLUGINS_AIX_default ON)
endif()
Add auto-exporting of symbols from tools so that plugins work on Windows The problem with plugins on Windows is that when building a plugin DLL it needs to explicitly link against something (an exe or DLL) if it uses symbols from that thing, and that thing must explicitly export those symbols. Also there's a limit of 65535 symbols that can be exported. This means that currently plugins only work on Windows when using BUILD_SHARED_LIBS, and that doesn't work with MSVC. This patch adds an LLVM_EXPORT_SYMBOLS_FOR_PLUGINS option, which when enabled automatically exports from all LLVM tools the symbols that a plugin could want to use so that a plugin can link against a tool directly. Plugins can specify what tool they link against by using PLUGIN_TOOL argument to llvm_add_library. The option can also be enabled on Linux, though there all it should do is restrict the set of symbols that are exported as by default all symbols are exported. This option is currently OFF by default, as while I've verified that it works with MSVC, linux gcc, and cygwin gcc, I haven't tried mingw gcc and I have no idea what will happen on OSX. Also unfortunately we can't turn on LLVM_ENABLE_PLUGINS when the option is ON as bugpoint-passes needs to be loaded by both bugpoint.exe and opt.exe which is incompatible with this approach. Also currently clang plugins don't work with this approach, which will be fixed in future patches. Differential Revision: http://reviews.llvm.org/D18826 llvm-svn: 270839
2016-05-26 19:16:43 +08:00
# This option makes utils/extract_symbols.py be used to determine the list of
[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-09 01:45:44 +08:00
# symbols to export from LLVM tools. This is necessary when on AIX or when using
# MSVC if you want to allow plugins. On AIX we don't show this option, and we
# enable it by default except when the LLVM libraries are set up for dynamic
# linking (due to incompatibility). With MSVC, note that the plugin has to
# explicitly link against (exactly one) tool so we can't unilaterally turn on
Add auto-exporting of symbols from tools so that plugins work on Windows The problem with plugins on Windows is that when building a plugin DLL it needs to explicitly link against something (an exe or DLL) if it uses symbols from that thing, and that thing must explicitly export those symbols. Also there's a limit of 65535 symbols that can be exported. This means that currently plugins only work on Windows when using BUILD_SHARED_LIBS, and that doesn't work with MSVC. This patch adds an LLVM_EXPORT_SYMBOLS_FOR_PLUGINS option, which when enabled automatically exports from all LLVM tools the symbols that a plugin could want to use so that a plugin can link against a tool directly. Plugins can specify what tool they link against by using PLUGIN_TOOL argument to llvm_add_library. The option can also be enabled on Linux, though there all it should do is restrict the set of symbols that are exported as by default all symbols are exported. This option is currently OFF by default, as while I've verified that it works with MSVC, linux gcc, and cygwin gcc, I haven't tried mingw gcc and I have no idea what will happen on OSX. Also unfortunately we can't turn on LLVM_ENABLE_PLUGINS when the option is ON as bugpoint-passes needs to be loaded by both bugpoint.exe and opt.exe which is incompatible with this approach. Also currently clang plugins don't work with this approach, which will be fixed in future patches. Differential Revision: http://reviews.llvm.org/D18826 llvm-svn: 270839
2016-05-26 19:16:43 +08:00
# LLVM_ENABLE_PLUGINS when it's enabled.
[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-09 01:45:44 +08:00
CMAKE_DEPENDENT_OPTION(LLVM_EXPORT_SYMBOLS_FOR_PLUGINS
"Export symbols from LLVM tools so that plugins can import them" OFF
"NOT ${CMAKE_SYSTEM_NAME} MATCHES AIX" ${LLVM_EXPORT_SYMBOLS_FOR_PLUGINS_AIX_default})
Add auto-exporting of symbols from tools so that plugins work on Windows The problem with plugins on Windows is that when building a plugin DLL it needs to explicitly link against something (an exe or DLL) if it uses symbols from that thing, and that thing must explicitly export those symbols. Also there's a limit of 65535 symbols that can be exported. This means that currently plugins only work on Windows when using BUILD_SHARED_LIBS, and that doesn't work with MSVC. This patch adds an LLVM_EXPORT_SYMBOLS_FOR_PLUGINS option, which when enabled automatically exports from all LLVM tools the symbols that a plugin could want to use so that a plugin can link against a tool directly. Plugins can specify what tool they link against by using PLUGIN_TOOL argument to llvm_add_library. The option can also be enabled on Linux, though there all it should do is restrict the set of symbols that are exported as by default all symbols are exported. This option is currently OFF by default, as while I've verified that it works with MSVC, linux gcc, and cygwin gcc, I haven't tried mingw gcc and I have no idea what will happen on OSX. Also unfortunately we can't turn on LLVM_ENABLE_PLUGINS when the option is ON as bugpoint-passes needs to be loaded by both bugpoint.exe and opt.exe which is incompatible with this approach. Also currently clang plugins don't work with this approach, which will be fixed in future patches. Differential Revision: http://reviews.llvm.org/D18826 llvm-svn: 270839
2016-05-26 19:16:43 +08:00
if(BUILD_SHARED_LIBS AND LLVM_EXPORT_SYMBOLS_FOR_PLUGINS)
message(FATAL_ERROR "BUILD_SHARED_LIBS not compatible with LLVM_EXPORT_SYMBOLS_FOR_PLUGINS")
endif()
if(LLVM_LINK_LLVM_DYLIB AND LLVM_EXPORT_SYMBOLS_FOR_PLUGINS)
message(FATAL_ERROR "LLVM_LINK_LLVM_DYLIB not compatible with LLVM_EXPORT_SYMBOLS_FOR_PLUGINS")
endif()
[CMake] Change the default value of LLVM_ENABLE_IDE There really aren't any generator behaviors that we need to take `CMAKE_EXTRA_GENERATOR` into account for. Where we need to take different behaviors for IDEs is mostly in enabling or disabling certain build system features that are optional but trip up the IDE UIs. Like the generation of lots of utility targets. By changing the LLVM_ENABLE_IDE default to only being on for multi-configuration generators, we allow gating where it will impact the UI presentation, while also supporting optionally disabling the generation if your tooling workflow encounters problems. Presently being able to manually disable extra target generation is useful for Visual Studio 2017's CMake integration where the IDE has trouble displaying and working with the large number of optional targets. llvm-svn: 344553
2018-10-16 05:14:19 +08:00
# By default we should enable LLVM_ENABLE_IDE only for multi-configuration
# generators. This option disables optional build system features that make IDEs
# less usable.
set(LLVM_ENABLE_IDE_default OFF)
if (CMAKE_CONFIGURATION_TYPES)
set(LLVM_ENABLE_IDE_default ON)
endif()
option(LLVM_ENABLE_IDE
"Disable optional build system features that cause problems for IDE generators"
${LLVM_ENABLE_IDE_default})
if (CMAKE_CONFIGURATION_TYPES AND NOT LLVM_ENABLE_IDE)
message(WARNING "Disabling LLVM_ENABLE_IDE on multi-configuration generators is not recommended.")
endif()
[CMake] Add LLVM_ENABLE_IDE option to better process sources for IDE's Summary: Currently LLVM has no way to support configuring for IDE's like CLion. Like XCode and MSVC's IDE, CLion needs to see all of the headers and tablegen files in order to properly parse the sources. This patch adds an `LLVM_ENABLE_IDE` option which can be used to configure for IDE's in general. It is used by `LLVMProcessSources.cmake` to determine if the extra source files should be added to the target. Unfortunately because of the low level of `LLVMProcessSources.cmake`, I'm not sure where the `LLVM_ENABLE_IDE` option should live. I choose `HandleLLVMOptions.cmake` so that out-of-tree Clang builds would correctly configure the option by default. Reviewers: beanz, mgorny, lebedev.ri Reviewed By: beanz Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D40219 llvm-svn: 322349
2018-01-12 12:01:41 +08:00
Fix evaluation of LLVM_DEFINITIONS CMake variable LLVM_DEFINITIONS collects preprocessor definitions provided for host compiler that builds llvm components. A function add_llvm_definitions was introduced in AddLLVMDefinitions.cmake to keep track of these definitions and was intended to be a replacement for CMake command add_definitions. Actually in many cases add_definitions is still used and the content of LLVM_DEFINITIONS is not actual now. On the other hand the current version of CMake allows getting set of definitions in a more convenient way. This fix implements evaluation of the variable by reading corresponding cmake property. Differential Revision: https://reviews.llvm.org/D31125 llvm-svn: 298336
2017-03-21 12:03:24 +08:00
function(get_compile_definitions)
get_directory_property(top_dir_definitions DIRECTORY ${CMAKE_SOURCE_DIR} COMPILE_DEFINITIONS)
foreach(definition ${top_dir_definitions})
if(DEFINED result)
string(APPEND result " -D${definition}")
else()
set(result "-D${definition}")
endif()
endforeach()
set(LLVM_DEFINITIONS "${result}" PARENT_SCOPE)
endfunction()
get_compile_definitions()
Re-commit: Make STATISTIC() values available programmatically Summary: It can be useful for tools to be able to retrieve the values of variables declared via STATISTIC() directly without having to emit them and parse them back. Use cases include: * Needing to report specific statistics to a test harness * Wanting to post-process statistics. For example, to produce a percentage of functions that were fully selected by GlobalISel Make this possible by adding llvm::GetStatistics() which returns an iterator_range that can be used to inspect the statistics that have been touched during execution. When statistics are disabled (NDEBUG and not LLVM_ENABLE_STATISTICS) this method will return an empty range. This patch doesn't address the effect of multiple compilations within the same process. In such situations, the statistics will be cumulative for all compilations up to the GetStatistics() call. Reviewers: qcolombet, rtereshin, aditya_nandakumar, bogner Reviewed By: rtereshin, bogner Subscribers: llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D43901 This re-commit fixes a missing include of <vector> which it seems clang didn't mind but G++ and MSVC objected to. It seems that, clang was ok with std::vector only being forward declared at the point of use since it was fully defined eventually but G++/MSVC both rejected it at the point of use. llvm-svn: 326738
2018-03-06 03:38:16 +08:00
Fix cmake's multi-config generators after r326738 LLVM_ENABLE_STATS isn't known at configure-time in these generators so we must defer it to build-time. llvm-svn: 326936
2018-03-08 03:32:36 +08:00
option(LLVM_FORCE_ENABLE_STATS "Enable statistics collection for builds that wouldn't normally enable it" OFF)
Annotate timeline in Instruments with passes and other timed regions. Summary: Instruments is a useful tool for finding performance issues in LLVM but it can be difficult to identify regions of interest on the timeline that we can use to filter the profiler or allocations instrument. Xcode 10 and the latest macOS/iOS/etc. added support for the os_signpost() API which allows us to annotate the timeline with information that's meaningful to LLVM. This patch causes timer start and end events to emit signposts. When used with -time-passes, this causes the passes to be annotated on the Instruments timeline. In addition to visually showing the duration of passes on the timeline, it also allows us to filter the profile and allocations instrument down to an individual pass allowing us to find the issues within that pass without being drowned out by the noise from other parts of the compiler. Using this in conjunction with the Time Profiler (in high frequency mode) and the Allocations instrument is how I found the SparseBitVector that should have been a BitVector and the DenseMap that could be replaced by a sorted vector a couple months ago. I added NamedRegionTimers to TableGen and used the resulting annotations to identify the slow portions of the Register Info Emitter. Some of these were placed according to educated guesses while others were placed according to hot functions from a previous profile. From there I filtered the profile to a slow portion and the aforementioned issues stood out in the profile. To use this feature enable LLVM_SUPPORT_XCODE_SIGNPOSTS in CMake and run the compiler under Instruments with -time-passes like so: instruments -t 'Time Profiler' bin/llc -time-passes -o - input.ll' Then open the resulting trace in Instruments. There was a talk at WWDC 2018 that explained the feature which can be found at https://developer.apple.com/videos/play/wwdc2018/405/ if you'd like to know more about it. Reviewers: bogner Reviewed By: bogner Subscribers: jdoerfert, mgorny, kristina, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D52954 llvm-svn: 354365
2019-02-20 02:18:31 +08:00
Fix builds for older macOS deployment targets after r354365 Surprisingly, check_symbol_exists is not sufficient. The macOS linker checks the called functions against a compatibility list for the given deployment target and check_symbol_exists doesn't trigger this check as it never calls the function. This fixes the GreenDragon bots where the deployment target is 10.9 llvm-svn: 354374
2019-02-20 03:45:03 +08:00
check_symbol_exists(os_signpost_interval_begin "os/signpost.h" macos_signposts_available)
if(macos_signposts_available)
check_cxx_source_compiles(
"#include <os/signpost.h>
int main() { os_signpost_interval_begin(nullptr, 0, \"\", \"\"); return 0; }"
macos_signposts_usable)
if(macos_signposts_usable)
set(LLVM_ENABLE_SUPPORT_XCODE_SIGNPOSTS "WITH_ASSERTS" CACHE STRING
"Enable support for Xcode signposts. Can be WITH_ASSERTS, FORCE_ON, FORCE_OFF")
string(TOUPPER "${LLVM_ENABLE_SUPPORT_XCODE_SIGNPOSTS}"
uppercase_LLVM_ENABLE_SUPPORT_XCODE_SIGNPOSTS)
if( uppercase_LLVM_ENABLE_SUPPORT_XCODE_SIGNPOSTS STREQUAL "WITH_ASSERTS" )
if( LLVM_ENABLE_ASSERTIONS )
set( LLVM_SUPPORT_XCODE_SIGNPOSTS 1 )
endif()
elseif( uppercase_LLVM_ENABLE_SUPPORT_XCODE_SIGNPOSTS STREQUAL "FORCE_ON" )
Annotate timeline in Instruments with passes and other timed regions. Summary: Instruments is a useful tool for finding performance issues in LLVM but it can be difficult to identify regions of interest on the timeline that we can use to filter the profiler or allocations instrument. Xcode 10 and the latest macOS/iOS/etc. added support for the os_signpost() API which allows us to annotate the timeline with information that's meaningful to LLVM. This patch causes timer start and end events to emit signposts. When used with -time-passes, this causes the passes to be annotated on the Instruments timeline. In addition to visually showing the duration of passes on the timeline, it also allows us to filter the profile and allocations instrument down to an individual pass allowing us to find the issues within that pass without being drowned out by the noise from other parts of the compiler. Using this in conjunction with the Time Profiler (in high frequency mode) and the Allocations instrument is how I found the SparseBitVector that should have been a BitVector and the DenseMap that could be replaced by a sorted vector a couple months ago. I added NamedRegionTimers to TableGen and used the resulting annotations to identify the slow portions of the Register Info Emitter. Some of these were placed according to educated guesses while others were placed according to hot functions from a previous profile. From there I filtered the profile to a slow portion and the aforementioned issues stood out in the profile. To use this feature enable LLVM_SUPPORT_XCODE_SIGNPOSTS in CMake and run the compiler under Instruments with -time-passes like so: instruments -t 'Time Profiler' bin/llc -time-passes -o - input.ll' Then open the resulting trace in Instruments. There was a talk at WWDC 2018 that explained the feature which can be found at https://developer.apple.com/videos/play/wwdc2018/405/ if you'd like to know more about it. Reviewers: bogner Reviewed By: bogner Subscribers: jdoerfert, mgorny, kristina, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D52954 llvm-svn: 354365
2019-02-20 02:18:31 +08:00
set( LLVM_SUPPORT_XCODE_SIGNPOSTS 1 )
Fix builds for older macOS deployment targets after r354365 Surprisingly, check_symbol_exists is not sufficient. The macOS linker checks the called functions against a compatibility list for the given deployment target and check_symbol_exists doesn't trigger this check as it never calls the function. This fixes the GreenDragon bots where the deployment target is 10.9 llvm-svn: 354374
2019-02-20 03:45:03 +08:00
elseif( uppercase_LLVM_ENABLE_SUPPORT_XCODE_SIGNPOSTS STREQUAL "FORCE_OFF" )
# We don't need to do anything special to turn off signposts.
elseif( NOT DEFINED LLVM_ENABLE_SUPPORT_XCODE_SIGNPOSTS )
# Treat LLVM_ENABLE_SUPPORT_XCODE_SIGNPOSTS like "FORCE_OFF" when it has not been
# defined.
else()
message(FATAL_ERROR "Unknown value for LLVM_ENABLE_SUPPORT_XCODE_SIGNPOSTS:"
" \"${LLVM_ENABLE_SUPPORT_XCODE_SIGNPOSTS}\"!")
Annotate timeline in Instruments with passes and other timed regions. Summary: Instruments is a useful tool for finding performance issues in LLVM but it can be difficult to identify regions of interest on the timeline that we can use to filter the profiler or allocations instrument. Xcode 10 and the latest macOS/iOS/etc. added support for the os_signpost() API which allows us to annotate the timeline with information that's meaningful to LLVM. This patch causes timer start and end events to emit signposts. When used with -time-passes, this causes the passes to be annotated on the Instruments timeline. In addition to visually showing the duration of passes on the timeline, it also allows us to filter the profile and allocations instrument down to an individual pass allowing us to find the issues within that pass without being drowned out by the noise from other parts of the compiler. Using this in conjunction with the Time Profiler (in high frequency mode) and the Allocations instrument is how I found the SparseBitVector that should have been a BitVector and the DenseMap that could be replaced by a sorted vector a couple months ago. I added NamedRegionTimers to TableGen and used the resulting annotations to identify the slow portions of the Register Info Emitter. Some of these were placed according to educated guesses while others were placed according to hot functions from a previous profile. From there I filtered the profile to a slow portion and the aforementioned issues stood out in the profile. To use this feature enable LLVM_SUPPORT_XCODE_SIGNPOSTS in CMake and run the compiler under Instruments with -time-passes like so: instruments -t 'Time Profiler' bin/llc -time-passes -o - input.ll' Then open the resulting trace in Instruments. There was a talk at WWDC 2018 that explained the feature which can be found at https://developer.apple.com/videos/play/wwdc2018/405/ if you'd like to know more about it. Reviewers: bogner Reviewed By: bogner Subscribers: jdoerfert, mgorny, kristina, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D52954 llvm-svn: 354365
2019-02-20 02:18:31 +08:00
endif()
endif()
endif()
[CMake] Provide an option to use relative paths in debug info CMake always uses absolute file paths in the generated compiler invocation which results in absolute file paths being embedded in debug info. This is undesirable when building a toolchain e.g. on bots as the debug info may embed the bot source checkout path which is meaningless anywhere else. This change introduces the LLVM_USE_RELATIVE_PATHS_IN_DEBUG_INFO which uses -fdebug-prefix-map (where supported) options to rewrite paths embedded into debug info with relative ones. Additionally, LLVM_SOURCE_PREFIX can be used to override the path to source directory with a different one. Differential Revision: https://reviews.llvm.org/D62622 llvm-svn: 362185
2019-05-31 09:34:51 +08:00
[CMake] Enable the use of -ffile-prefix-map This handles not paths embedded in debug info, but also in sources. Since the use of this flag is controlled by an option, rather than replacing the new option, we add a new option. Differential Revision: https://reviews.llvm.org/D76018
2020-03-12 01:59:12 +08:00
set(LLVM_SOURCE_PREFIX "" CACHE STRING "Use prefix for sources")
[CMake] Provide an option to use relative paths in debug info CMake always uses absolute file paths in the generated compiler invocation which results in absolute file paths being embedded in debug info. This is undesirable when building a toolchain e.g. on bots as the debug info may embed the bot source checkout path which is meaningless anywhere else. This change introduces the LLVM_USE_RELATIVE_PATHS_IN_DEBUG_INFO which uses -fdebug-prefix-map (where supported) options to rewrite paths embedded into debug info with relative ones. Additionally, LLVM_SOURCE_PREFIX can be used to override the path to source directory with a different one. Differential Revision: https://reviews.llvm.org/D62622 llvm-svn: 362185
2019-05-31 09:34:51 +08:00
option(LLVM_USE_RELATIVE_PATHS_IN_DEBUG_INFO "Use relative paths in debug info" OFF)
if(LLVM_USE_RELATIVE_PATHS_IN_DEBUG_INFO)
check_c_compiler_flag("-fdebug-prefix-map=foo=bar" SUPPORTS_FDEBUG_PREFIX_MAP)
if(LLVM_ENABLE_PROJECTS_USED)
get_filename_component(source_root "${LLVM_MAIN_SRC_DIR}/.." ABSOLUTE)
else()
set(source_root "${LLVM_MAIN_SRC_DIR}")
endif()
file(RELATIVE_PATH relative_root "${source_root}" "${CMAKE_BINARY_DIR}")
append_if(SUPPORTS_FDEBUG_PREFIX_MAP "-fdebug-prefix-map=${CMAKE_BINARY_DIR}=${relative_root}" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
append_if(SUPPORTS_FDEBUG_PREFIX_MAP "-fdebug-prefix-map=${source_root}/=${LLVM_SOURCE_PREFIX}" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
add_flag_if_supported("-no-canonical-prefixes" NO_CANONICAL_PREFIXES)
endif()
[CMake] Enable the use of -ffile-prefix-map This handles not paths embedded in debug info, but also in sources. Since the use of this flag is controlled by an option, rather than replacing the new option, we add a new option. Differential Revision: https://reviews.llvm.org/D76018
2020-03-12 01:59:12 +08:00
option(LLVM_USE_RELATIVE_PATHS_IN_FILES "Use relative paths in sources and debug info" OFF)
if(LLVM_USE_RELATIVE_PATHS_IN_FILES)
check_c_compiler_flag("-ffile-prefix-map=foo=bar" SUPPORTS_FFILE_PREFIX_MAP)
if(LLVM_ENABLE_PROJECTS_USED)
get_filename_component(source_root "${LLVM_MAIN_SRC_DIR}/.." ABSOLUTE)
else()
set(source_root "${LLVM_MAIN_SRC_DIR}")
endif()
file(RELATIVE_PATH relative_root "${source_root}" "${CMAKE_BINARY_DIR}")
append_if(SUPPORTS_FFILE_PREFIX_MAP "-ffile-prefix-map=${CMAKE_BINARY_DIR}=${relative_root}" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
append_if(SUPPORTS_FFILE_PREFIX_MAP "-ffile-prefix-map=${source_root}/=${LLVM_SOURCE_PREFIX}" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
add_flag_if_supported("-no-canonical-prefixes" NO_CANONICAL_PREFIXES)
endif()