summaryrefslogtreecommitdiffstats
path: root/llvm/cmake/modules
Commit message (Collapse)AuthorAgeFilesLines
...
* [X86] Quick fix for build bot failure (r297127) due to unused variable.Ayman Musa2017-03-071-2/+1
| | | | llvm-svn: 297130
* [X86][AVX512] Adding new LLVM TableGen backend which generates the EVEX2VEX ↵Ayman Musa2017-03-071-1/+2
| | | | | | | | | | | | compressing tables. X86EvexToVex machine instruction pass compresses EVEX encoded instructions by replacing them with their identical VEX encoded instructions when possible. It uses manually supported 2 large tables that map the EVEX instructions to their VEX ideticals. This TableGen backend replaces the tables by automatically generating them. Differential Revision: https://reviews.llvm.org/D30451 llvm-svn: 297127
* Revert r296730, "cmake: Configure the ThinLTO cache directory when using ELF ↵Peter Collingbourne2017-03-031-14/+5
| | | | | | | | | lld or gold." Causes a build failure on the clang-with-thin-lto-ubuntu bot. http://lab.llvm.org:8011/builders/clang-with-thin-lto-ubuntu/builds/2117/steps/build-stage3-compiler/logs/stdio llvm-svn: 296850
* CMake: Clean up VersionFromVCS.cmakeTom Stellard2017-03-021-33/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Fix a few problems in VersionFromVCS.cmake to make it more reliable: - Stop using git svn info to retrieve the svn revision. I am unable to determine what the svn revision returned by this command means. During my testing this command returned a revision from a month ago which was not the HEAD of any of my local branches. Also, this revision was never actually added to the version string due to a typo in the script. All it was used for was to reject the revision number returned by git svn find-rev HEAD when the revision numbers didn't match. - Populate GIT_COMMIT even when we detect a git repo without any svn information. Reviewers: mehdi_amini, beanz Reviewed By: beanz Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D30092 llvm-svn: 296829
* cmake: Configure the ThinLTO cache directory when using ELF lld or gold.Peter Collingbourne2017-03-021-5/+14
| | | | | | Differential Revision: https://reviews.llvm.org/D30522 llvm-svn: 296730
* enable building with LTO on Windows using clang-cl and lldBob Haarman2017-03-011-10/+27
| | | | | | | | | | | | | | 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
* [CMake] Support externalizing debug info on non-Darwin platformsPetr Hosek2017-02-171-2/+10
| | | | | | | | On other platorms, we use objcopy to export the debug info. Differential Revision: https://reviews.llvm.org/D28575 llvm-svn: 295481
* [Tablegen] Instrumenting table gen DAGGenISelDAGAditya Nandakumar2017-02-141-0/+7
| | | | | | | | | | To help assist in debugging ISEL or to prioritize GlobalISel backend work, this patch adds two more tables to <Target>GenISelDAGISel.inc - one which contains the patterns that are used during selection and the other containing include source location of the patterns Enabled through CMake varialbe LLVM_ENABLE_DAGISEL_COV llvm-svn: 295081
* [CMake] Fix pthread handling for out-of-tree buildsEric Fiselier2017-02-102-3/+7
| | | | | | | | | | | | | | | LLVM defines `PTHREAD_LIB` which is used by AddLLVM.cmake and various projects to correctly link the threading library when needed. Unfortunately `PTHREAD_LIB` is defined by LLVM's `config-ix.cmake` file which isn't installed and therefore can't be used when configuring out-of-tree builds. This causes such builds to fail since `pthread` isn't being correctly linked. This patch attempts to fix that problem by renaming and exporting `LLVM_PTHREAD_LIB` as part of`LLVMConfig.cmake`. I renamed `PTHREAD_LIB` because It seemed likely to cause collisions with downstream users of `LLVMConfig.cmake`. llvm-svn: 294690
* [CMake] Fix standalone project builds broken in r294514Chris Bieneman2017-02-091-0/+1
| | | | | | This patch sets the global property indicating that target registration is complete for standalone sub-project builds. llvm-svn: 294602
* [CMake] Fix `is_llvm_target_library` and support out-of-order componentsChris Bieneman2017-02-081-11/+73
| | | | | | | | | | | | Summary: This patch is required by D28855, and enables us to rely on CMake's ability to handle out of order target dependencies. Reviewers: mgorny, chapuni, bryant Subscribers: llvm-commits, jgosnell Differential Revision: https://reviews.llvm.org/D28869 llvm-svn: 294514
* [CMake] Fix USE_LLVM_SANITIZER configuration for out-of-tree builds.Eric Fiselier2017-02-071-2/+5
| | | | | | | | | | | | | | | | | Summary: r291918 changed `HandleLLVMOptions.cmake` to add `-fsanitize-blacklist=<llvm-file>` when `LLVM_USE_SANITIZER=Undefined` is specified. This breaks out-of-tree users of `LLVM_USE_SANITIZER` since that file is not present. This patch fixes the issue by checking if the file exists first. Reviewers: mgorny, bogner, vitalybuka, krasin Reviewed By: krasin Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D29686 llvm-svn: 294367
* [CMake] Move ninja job pool options to HandleLLVMOptionsChris Bieneman2017-02-071-0/+24
| | | | | | 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
* CMake is funky on detecting Intel 17 as GCC compatible.Yichao Yu2017-01-261-0/+2
| | | | | | | | | | | | | | Summary: This adds a fallback in case that the Intel compiler is failed to be detected correctly. Reviewers: chapuni Reviewed By: chapuni Subscribers: llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D27610 llvm-svn: 293230
* cmake: Only sanitize use-after-scope if the host compiler supports itJustin Bogner2017-01-181-1/+2
| | | | | | | | | 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
* Enabled -fsanitize-address-use-after-scope for -DLLVM_USE_SANITIZER=AddressVitaly Buka2017-01-171-0/+3
| | | | | | | | Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D28823 llvm-svn: 292256
* [cmake] Update SOVERSION for the new versioning schemeMichal Gorny2017-01-171-5/+3
| | | | | | | | | | | | | | | Update SOVERSION to use just the major version number rather than major+minor, to match the new versioning scheme where only major is used to indicate API/ABI version. Since two-digit SOVERSIONs were introduced post 3.9 branching, this change does not risk any SOVERSION collisions. In the past, two-component X.Y SOVERSIONs were shortly used but those will not interfere with the new ones since the new versions start at 4. Differential Revision: https://reviews.llvm.org/D28730 llvm-svn: 292255
* Add a LLVM_USE_LINKER that defines the linker to use when building LLVMMehdi Amini2017-01-151-3/+13
| | | | | | | | | | | | | | | 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
* Fix UBSan bots by blacklisting bits/stl_tree.h.Ivan Krasin2017-01-131-0/+2
| | | | | | | | | | | | | | | | Summary: libstdc++ has some undefined behavior in bits/stl_tree.h that has recently became excercised by some of the LLVM code. Given that fixing libstdc++ will take years, adding the file into a blacklist to fix bots seems like a necessity. Reviewers: vitalybuka Subscribers: llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D28686 llvm-svn: 291918
* Add -Wl,-color-diagnostics if a linker supports the option.Rui Ueyama2017-01-112-0/+16
| | | | | | Differential Revision: https://reviews.llvm.org/D28046 llvm-svn: 291719
* Add the 'googlemock' component of Google Test to LLVM's unittest libraries.Chandler Carruth2017-01-101-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I have two immediate motivations for adding this: 1) It makes writing expectations in tests *dramatically* easier. A quick example that is a taste of what is possible: std::vector<int> v = ...; EXPECT_THAT(v, UnorderedElementsAre(1, 2, 3)); This checks that v contains '1', '2', and '3' in some order. There are a wealth of other helpful matchers like this. They tend to be highly generic and STL-friendly so they will in almost all cases work out of the box even on custom LLVM data structures. I actually find the matcher syntax substantially easier to read even for simple assertions: EXPECT_THAT(a, Eq(b)); EXPECT_THAT(b, Ne(c)); Both of these make it clear what is being *tested* and what is being *expected*. With `EXPECT_EQ` this is implicit (the LHS is expected, the RHS is tested) and often confusing. With `EXPECT_NE` it is just not clear. Even the failure error messages are superior with the matcher based expectations. 2) When testing any kind of generic code, you are continually defining dummy types with interfaces and then trying to check that the interfaces are manipulated in a particular way. This is actually what mocks are *good* for -- testing *interface interactions*. With generic code, there is often no "fake" or other object that can be used. For a concrete example of where this is currently causing significant pain, look at the pass manager unittests which are riddled with counters incremented when methods are called. All of these could be replaced with mocks. The result would be more effective at testing the code by having tighter constraints. It would be substantially more readable and maintainable when updating the code. And the error messages on failure would have substantially more information as mocks automatically record stack traces and other information *when the API is misused* instead of trying to diagnose it after the fact. I expect that #1 will be the overwhelming majority of the uses of gmock, but I think that is sufficient to justify having it. I would actually like to update the coding standards to encourage the use of matchers rather than any other form of `EXPECT_...` macros as they are IMO a strict superset in terms of functionality and readability. I think that #2 is relatively rarely useful, but there *are* cases where it is useful. Historically, I think misuse of actual mocking as described in #2 has led to resistance towards this framework. I am actually sympathetic to this -- mocking can easily be overused. However I think this is not a significant concern in LLVM. First and foremost, LLVM has very careful and rare exposure of abstract interfaces or dependency injection, which are the most prone to abuse with mocks. So there are few opportunities to abuse them. Second, a large fraction of LLVM's unittests are testing *generic code* where mocks actually make tremendous sense. And gmock is well suited to building interfaces that exercise generic libraries. Finally, I still think we should be willing to have testing utilities in tree even if they should be used rarely. We can use code review to help guide the usage here. For a longer and more complete discussion of this, see the llvm-dev thread here: http://lists.llvm.org/pipermail/llvm-dev/2017-January/108672.html The general consensus seems that this is a reasonable direction to start down, but that doesn't mean we should race ahead and use this everywhere. I have one test that is blocked on this to land and that was specifically used as an example. Before widespread adoption, I'm going to work up some (brief) guidelines as some of these facilities should be used sparingly and carefully. Differential Revision: https://reviews.llvm.org/D28156 llvm-svn: 291606
* [gtest] Detect warning flags using the positive spelling.Chandler Carruth2017-01-061-2/+2
| | | | | | | | | | | | | | | | | | | | | Some GCC versions will accept any warning flag name after a '-Wno-', which would cause us to try to disable warnings with names GCC didn't understand. This will silently succeed unless there is some other output from GCC in which case we get weird cc1plus warnings about the warning name being bogus. There is still the issue that gtest sets warning flags for building gtest-all.cc using weird 'add_definitions' and the fact that there is a GCC version which warns on the variadic macro usage in gtest under -pedantic, but has no flag analogous to Clang's -Wgnu-zero-variadic-macro-argumnets to suppress this warning. I haven't been able to come up with any good solution here. The closest is to turn off -pedantic for those versions of GCC, but that seems really nasty. For now, those versinos of GCC aren't warning clean. If anyone is broken by this, I'll work on CMake logic to detect and disable -pedantic in these cases. llvm-svn: 291299
* [cmake] Canonicalize CMake booleans to 0/1 for lit interopMichal Gorny2017-01-061-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Canonicalize all CMake booleans to 0/1 before passing them to lit, to ensure that the Python side handles all of them consistently and correctly. 0/1 is a safe choice of values that trigger the same boolean interpretation in CMake, Python and C++. Furthermore, using them without quotes improves the chance Python will explicitly fail when an incorrect value (such as ON/OFF, TRUE/FALSE, YES/NO) is accidentally passed, rather than silently misinterpreting the value. This replaces a lot of different logics spread around lit site files, attempting to partially reproduce the boolean logic used in CMake and usually silently failing when an uncommon value was used instead. In fact, some of them were never working correctly since different values were assigned in CMake and checked in Python. The alternative solution could be to create a common parser for CMake booleans in lit and use it consistently throughout the site files. However, it does not seem like the best idea to create redundant implementation of the same logic and have to follow upstream if it ever is extended to handle more values. Differential Revision: https://reviews.llvm.org/D28294 llvm-svn: 291284
* [gtest] Fix the way we disable a warning for unittests.Chandler Carruth2017-01-041-0/+4
| | | | | | | | I somehow wrote this fix and then lost it prior to commit. Really sorry about the noise. This should fix some issues with hacking add_definition to do things with warning flags. llvm-svn: 291033
* Fix the MSVC version check.Zachary Turner2017-01-031-2/+2
| | | | | | | | | | I'm not sure what determines the minor version, but it appears that it's possible for a fully updated, release version of VS2015 with Update 3 can go (at least) as low as 19.00.24213.1. Updating the compiler version check to account for this so we don't generate superfluous warnings. llvm-svn: 290914
* [cmake] Add LLVM_ENABLE_DIA_SDK option, and expose it in LLVMConfigMichal Gorny2017-01-021-0/+2
| | | | | | | | | | | | | | | Add an explicit LLVM_ENABLE_DIA_SDK option to control building support for DIA SDK-based debugging. Control its value to match whether DIA SDK support was found and expose it in LLVMConfig (alike LLVM_ENABLE_ZLIB). Its value is needed for LLDB to determine whether to run tests requiring DIA support. Currently it is obtained from llvm/Config/config.h; however, this file is not available for standalone builds. Following this change, LLDB will be modified to use the value from LLVMConfig. Differential Revision: https://reviews.llvm.org/D26255 llvm-svn: 290818
* Enable '-Wstring-conversion' and fix some bad asserts that it helpedChandler Carruth2016-12-231-0/+3
| | | | | | | | find. Notable is the assert in NewGVN which had no effect because of the bug. llvm-svn: 290400
* Pass -Wa,-mbig-obj in 64-bit mingw buildsReid Kleckner2016-12-221-0/+7
| | | | | | | | | | | 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
* Fix some remaining documentation references to MSVC 2013Reid Kleckner2016-12-151-7/+7
| | | | | | | | MSVC 2015 has been the minimum supported version of VS since October. Differential Revision: https://reviews.llvm.org/D25710 llvm-svn: 289854
* [CMake] Minor change to symlink generation for LLDBChris Bieneman2016-12-151-2/+7
| | | | | | | | If OUTPUT_DIR is not specified we can assume the symlink is linking to a file in the same directory, so we can use $<TARGET_FILE_NAME:${target}> to create a relative symlink. In the case of LLDB, when we build a framework, we are creating symlinks in a different directory than the file we're pointing to, and we don't install those links. To make this work in the build directory we can use $<TARGET_FILE:${target}> instead, which uses the full path to the target. llvm-svn: 289840
* [CMake] Multi-target builtins buildPetr Hosek2016-12-121-0/+9
| | | | | | | | | | | | | | This change enables building builtins for multiple different targets using LLVM runtimes directory. To specify the builtin targets to be built, use the LLVM_BUILTIN_TARGETS variable, where the value is the list of targets. To pass a per target variable to the builtin build, you can set BUILTINS_<target>_<variable> where <variable> will be passed to the builtin build for <target>. Differential Revision: https://reviews.llvm.org/D26652 llvm-svn: 289491
* [libFuzzer] switch all libFuzzer tests to use ↵Kostya Serebryany2016-12-101-1/+1
| | | | | | -fsanitize-coverage=trace-pc-guard. Support for the previosly used instrumentation will be removed in the following changes llvm-svn: 289311
* Remove /Zc:sizedDealloc- from the MSVC buildReid Kleckner2016-12-091-5/+0
| | | | | | | | | | According to the connect bug (https://connect.microsoft.com/VisualStudio/feedback/details/1351894), this was only necessary with pre-release versions of MSVC 2015. Fixes PR23513 llvm-svn: 289257
* [CMake] Fixing clang standalone buildChris Bieneman2016-12-061-0/+4
| | | | | | I broke this in r288770. llvm-svn: 288829
* [CMake] Cleanup TableGen include flagsChris Bieneman2016-12-061-10/+4
| | | | | | | | | | It is kinda crazy to have llvm/include and llvm/lib/Target in the include path for every tablegen invocation for every tablegen-like tool. This patch removes those flags from the tablgen function that is called everywhere by instead creating a variable LLVM_TABLEGEN_FLAGS which is setup in the LLVM source directories. This removes TableGen.cmake's dependency on LLVM_MAIN_SRC_DIR, and LLVM_MAIN_INCLUDE_DIR. llvm-svn: 288770
* [CMake] Fix symlink refactor for multi-configuration generatorsChris Bieneman2016-12-051-3/+23
| | | | | | This fix, while a bit complicated, preserves the reusability while fixing the issues reported on llvm-commits with visual studio generators. llvm-svn: 288679
* [cmake] Include component in Sphinx install rulesMichal Gorny2016-12-051-0/+2
| | | | | | | | | Include component in install rules for Sphinx targets. Based on a similar suggestion for other doc targets in D24935. Differential Revision: https://reviews.llvm.org/D24982 llvm-svn: 288656
* [CMake] Refactor add_llvm_tool_symlink for reuseChris Bieneman2016-12-051-13/+24
| | | | | | The old implementation of add_llvm_tool_symlink could fail in odd ways when building out of tree. This version solves that problem by not using the LLVM_* variables, and instead reaeding the target's properties. llvm-svn: 288632
* build: allow specifying the component to `llvm_install_symlink`Saleem Abdulrasool2016-12-031-4/+8
| | | | | | | | Add an optional parameter to `llvm_install_symlink` which allows the symlink installation to be placed into a specific component rather than the default value. llvm-svn: 288600
* cmake: Set rpath for loadable modules as well as shared libraries.Peter Collingbourne2016-11-281-0/+1
| | | | | | | | | | | This fixes a regression introduced by r285714: we weren't setting the rpath on LLVMgold.so correctly. Spotted by mark@chromium.org! Differential Revision: https://reviews.llvm.org/D27176 llvm-svn: 288076
* [CMake] Apply sandbox profile to target not directoryChris Bieneman2016-11-191-5/+5
| | | | | | When LLVM_DEPENDENCY_DEBUGGING=On we should apply the sandbox only on the target, not the directory. This is important for directories that create more than one target, or for nested directories. llvm-svn: 287415
* [CMake] Error when LTO and lld are enabled on DarwinPetr Hosek2016-11-171-0/+3
| | | | | | | | lld on Darwin does not currently support LTO. Differential Revision: https://reviews.llvm.org/D26715 llvm-svn: 287256
* [cmake] Move LLVM_BUILD_STATIC check to an earlier pointPavel Labath2016-11-171-4/+0
| | | | | | | | | | | | | | | | | | | | Summary: The motivation for this is to enable correct detection of dlopen() on Android. Android does not provide a static version of libdl, so if we add the -static flag after performing the check, it will succeed even though subsequent link steps will fail. With this change we correctly detect the absence of libdl in a LLVM_BUILD_STATIC build on Android. The link itself still does not succeed because the code does not check the result of this check properly, but I plan to fix that in a separate change. Reviewers: beanz Subscribers: danalbert, mgorny, srhines, tberghammer, llvm-commits Differential Revision: https://reviews.llvm.org/D26463 llvm-svn: 287220
* [CMake] [Darwin] Add support for debugging tablegen dependenciesChris Bieneman2016-11-171-1/+23
| | | | | | | | This patch adds an option to the build system LLVM_DEPENDENCY_DEBUGGING. Over time I plan to extend this to do more complex verifications, but the initial patch causes compile errors wherever there is missing a dependency on intrinsics_gen. Because intrinsics_gen is a compile-time dependency not a link-time dependency, everything that relies on the headers generated in intrinsics_gen needs an explicit dependency. llvm-svn: 287207
* Reverting r285406, which was a temporary workaround to get one of the ↵Aaron Ballman2016-11-141-5/+3
| | | | | | documentation bots upgraded to something newer than GCC 4.7. This restores the check for GCC 4.8. llvm-svn: 286822
* CMake: make LLVM_OPTIMIZED_TABLEGEN friendly with LLVM_EXTERNAL_CLANG_SOURCE_DIRMehdi Amini2016-11-111-0/+5
| | | | | | | | This is need because of clang-tblgen Differential Revision: https://reviews.llvm.org/D26483 llvm-svn: 286560
* cmake: Don't try to install exports if there aren't anyJustin Bogner2016-11-082-2/+8
| | | | | | | | | When using LLVM_DISTRIBUTION_COMPONENTS, it's possible for LLVM's export list to be empty. If this happens the install(EXPORTS) command will fail, but since there isn't anything to install anyway we really just want to skip it. llvm-svn: 286209
* [CMake] Fix llvm_setup_rpath functionMandeep Singh Grang2016-11-081-16/+16
| | | | | | | | | | | | | | | | | | | Summary: Set _install_rpath to CMAKE_INSTALL_RPATH if it is defined, so that eventually INSTALL_RPATH is set to CMAKE_INSTALL_RPATH. The "if(NOT DEFINED CMAKE_INSTALL_RPATH)" was missing a corresponding else clause. This also cleans up the fix made in r285908. Patch by Azharuddin Mohammed Reviewers: john.brawn, sgundapa, beanz Subscribers: chapuni, mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D26289 llvm-svn: 286184
* cmake: When using LLVM_DISTRIBUTION_COMPONENTS, adjust LLVMExports accordinglyJustin Bogner2016-11-042-8/+29
| | | | | | | This Makes sure we only export targets that we're distributing, since cmake will fail to import the file otherwise due to missing targets. llvm-svn: 286024
* [CMake] Make CMAKE_INSTALL_RPATH work againJohn Brawn2016-11-031-4/+6
| | | | | | | | r285714 made it so that when CMAKE_INSTALL_RPATH is set _install_rpath is not set, but that means INSTALL_RPATH gets set to an empty string which isn't what we want. Fix this by setting INSTALL_RPATH only when _install_rpath is set. llvm-svn: 285908
OpenPOWER on IntegriCloud