aboutsummaryrefslogtreecommitdiff
path: root/polly/cmake
AgeCommit message (Collapse)AuthorFilesLines
2024-05-25[polly] Revise IDE folder structure (#89752)Michael Kruse1-2/+2
Update the folder titles for targets in the monorepository that have not seen taken care of for some time. These are the folders that targets are organized in Visual Studio and XCode (`set_property(TARGET <target> PROPERTY FOLDER "<title>")`) when using the respective CMake's IDE generator. * Ensure that every target is in a folder * Use a folder hierarchy with each LLVM subproject as a top-level folder * Use consistent folder names between subprojects * When using target-creating functions from AddLLVM.cmake, automatically deduce the folder. This reduces the number of `set_property`/`set_target_property`, but are still necessary when `add_custom_target`, `add_executable`, `add_library`, etc. are used. A LLVM_SUBPROJECT_TITLE definition is used for that in each subproject's root CMakeLists.txt.
2023-12-25[polly] [CMake] Create component and install target in add_polly_library ↵Violet Purcell1-0/+3
(#66598) Currently there's no component for LLVMPolly and PollyISL, however they are added to exports whether or not they are installed. This commit calls add_llvm_install_targets in the add_polly_library function to allow installation of LLVMPolly and PollyISL via distribution components, so they can be installed without also installing libPolly.a. Closes: https://github.com/llvm/llvm-project/pull/66598
2023-09-05[polly] Dynamic libraries are not supported on CygwinCarlo Bramini1-1/+1
Cygwin shares the same limitations as traditional Windows executables for dynamic library loading, so disable building the dynamic library on Cygwin targets. Differential Revision: https://reviews.llvm.org/D155796
2023-03-08[Polly] Remove Polly-ACC.Michael Kruse2-12/+0
Polly-ACC is unmaintained and since it has never been ported to the NPM pipeline, since D136621 it is not even accessible anymore without manually specifying the passes on the `opt` command line. Since there is no plan to put it to a maintainable state, remove it from Polly. Reviewed By: grosser Differential Revision: https://reviews.llvm.org/D142580
2023-01-13[cmake] Fix path to LLVMConfig.cmake for multi-config buildsNhat Nguyen1-1/+2
D139623 replaces CMAKE_CFG_INTDIR with '.' for multi-config builds. However, this change has not been reflected in mlir, flang, polly, lld, and clang. The patch updates the path to LLVMConfig.cmake for those projects. Reviewed By: sebastian-ne Differential Revision: https://reviews.llvm.org/D141538
2022-11-25Add version to all LLVM cmake packageThomas Preud'homme3-1/+24
Add a version to non-LLVM cmake package so that users needing an exact version match can use the version parameter to find_package. Also adjust the find_package(LLVM) to use an exact version match as well. Reviewed By: arsenm, stellaraccident, mceier Differential Revision: https://reviews.llvm.org/D138274
2022-11-25Revert: Add version to all LLVM cmake packageThomas Preud'homme3-24/+1
Summary: This reverts commit ad485b71b51168ce13282ae159bd8feff48baf84. Reviewers: Subscribers:
2022-11-20Add version to all LLVM cmake packageThomas Preud'homme3-1/+24
Add a version to non-LLVM cmake package so that users needing an exact version match can use the version parameter to find_package. Also adjust the find_package(LLVM) to use an exact version match as well. Reviewed By: arsenm, stellaraccident Differential Revision: https://reviews.llvm.org/D138274
2022-09-14[CMake] Avoid `LLVM_BINARY_DIR` when other more specific variable are ↵John Ericson1-1/+1
better-suited, part 2 A simple sed doing these substitutions: - `${LLVM_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}\>` -> `${LLVM_LIBRARY_DIR}` - `${LLVM_BINARY_DIR}/bin\>` -> `${LLVM_TOOLS_BINARY_DIR}` where `\>` means "word boundary". The only manual modifications were reverting changes in - `runtimes/CMakeLists.txt` because these were "entry points" where we wanted to tread carefully not not introduce a "loop" which would end with an undefined variable being expanded to nothing. There are some `${LLVM_BINARY_DIR}/lib` without the `${LLVM_LIBDIR_SUFFIX}`, but these refer to the lib subdirectory of the source (`llvm/lib`). That `lib` is automatically appended to make the local `CMAKE_CURRENT_BINARY_DIR` value by `add_subdirectory`; since the directory name in the source tree is fixed without any suffix, the corresponding `CMAKE_CURRENT_BINARY_DIR` will also be. We therefore do not replace it but leave it as-is. This picks up where D133828 left off, getting the occurrences with*out* `CMAKE_CFG_INTDIR`. But this is difficult to do correctly and so not done in the (retroactively) previous diff. This hopefully increases readability overall, and also decreases the usages of `LLVM_LIBDIR_SUFFIX`, preparing us for D130586. Reviewed By: sebastian-ne Differential Revision: https://reviews.llvm.org/D132316
2022-08-25Revert "[CMake] Avoid `LLVM_BINARY_DIR` when other more specific variable ↵John Ericson1-1/+1
are better-suited" This reverts commit ad8c34bc3089d847a09bb740f7a58c96073e0959.
2022-08-24[CMake] Avoid `LLVM_BINARY_DIR` when other more specific variable are ↵John Ericson1-1/+1
better-suited A simple sed doing these substitutions: - `${LLVM_BINARY_DIR}/(\$\{CMAKE_CFG_INTDIR}/)?lib(${LLVM_LIBDIR_SUFFIX})?\>` -> `${LLVM_LIBRARY_DIR}` - `${LLVM_BINARY_DIR}/(\$\{CMAKE_CFG_INTDIR}/)?bin\>` -> `${LLVM_TOOLS_BINARY_DIR}` where `\>` means "word boundary". The only manual modifications were reverting changes in - `compiler-rt/cmake/Modules/CompilerRTUtils.cmake - `runtimes/CMakeLists.txt` because these were "entry points" where we wanted to tread carefully not not introduce a "loop" which would end with an undefined variable being expanded to nothing. This hopefully increases readability overall, and also decreases the usages of `LLVM_LIBDIR_SUFFIX`, preparing us for D130586. Reviewed By: sebastian-ne Differential Revision: https://reviews.llvm.org/D132316
2022-08-18Revert "[cmake] Use `CMAKE_INSTALL_LIBDIR` too"John Ericson2-5/+5
This reverts commit f7a33090a91015836497c75f173775392ab0304d. Unfortunately this causes a number of failures that didn't show up in my local build.
2022-08-18[cmake] Use `CMAKE_INSTALL_LIBDIR` tooJohn Ericson2-5/+5
We held off on this before as `LLVM_LIBDIR_SUFFIX` conflicted with it. Now we return this. `LLVM_LIBDIR_SUFFIX` is kept as a deprecated way to set `CMAKE_INSTALL_LIBDIR`. The other `*_LIBDIR_SUFFIX` are just removed entirely. I imagine this is too potentially-breaking to make LLVM 15. That's fine. I have a more minimal version of this in the disto (NixOS) patches for LLVM 15 (like previous versions). This more expansive version I will test harder after the release is cut. Reviewed By: sebastian-ne, ldionne, #libc, #libc_abi Differential Revision: https://reviews.llvm.org/D130586
2022-07-25[cmake] Support custom package install pathsJohn Ericson1-8/+15
Firstly, we we make an additional GNUInstallDirs-style variable. With NixOS, for example, this is crucial as we want those to go in `${dev}/lib/cmake` not `${out}/lib/cmake` as that would a cmake subdir of the "regular" libdir, which is installed even when no one needs to do any development. Secondly, we make *Config.cmake robust to absolute package install paths. We for NixOS will in fact be passing them absolute paths to make the `${dev}` vs `${out}` distinction mentioned above, and the GNUInstallDirs-style variables are suposed to support absolute paths in general so it's good practice besides the NixOS use-case. Thirdly, we make `${project}_INSTALL_PACKAGE_DIR` CACHE PATHs like other install dirs are. Reviewed By: sebastian-ne Differential Revision: https://reviews.llvm.org/D117973
2022-01-18[polly][cmake] Use `GNUInstallDirs` to support custom installation dirsJohn Ericson1-9/+11
I am breaking apart D99484 so the cause of build failures is easier to understand. Reviewed By: Meinersbur Differential Revision: https://reviews.llvm.org/D117541
2022-01-16Revert "[cmake] Use `GNUInstallDirs` to support custom installation dirs."John Ericson1-11/+9
https://lab.llvm.org/buildbot/#/builders/46/builds/21146 Still have this odd error, not sure how to reproduce, so I will just try breaking up my patch. This reverts commit 4a678f8072004eff9214c1a4e1836a14abb69535.
2022-01-16[cmake] Use `GNUInstallDirs` to support custom installation dirs.John Ericson1-9/+11
This is the original patch in my GNUInstallDirs series, now last to merge as the final piece! It arose as a new draft of D28234. I initially did the unorthodox thing of pushing to that when I wasn't the original author, but since I ended up - Using `GNUInstallDirs`, rather than mimicking it, as the original author was hesitant to do but others requested. - Converting all the packages, not just LLVM, effecting many more projects than LLVM itself. I figured it was time to make a new revision. I have used this patch series (and many back-ports) as the basis of https://github.com/NixOS/nixpkgs/pull/111487 for my distro (NixOS), which was merged last spring (2021). It looked like people were generally on board in D28234, but I make note of this here in case extra motivation is useful. --- As pointed out in the original issue, a central tension is that LLVM already has some partial support for these sorts of things. Variables like `COMPILER_RT_INSTALL_PATH` have already been dealt with. Variables like `LLVM_LIBDIR_SUFFIX` however, will require further work, so that we may use `CMAKE_INSTALL_LIBDIR`. These remaining items will be addressed in further patches. What is here is now rote and so we should get it out of the way before dealing more intricately with the remainder. Reviewed By: #libunwind, #libc, #libc_abi, compnerd Differential Revision: https://reviews.llvm.org/D99484
2022-01-15Revert "[cmake] Use `GNUInstallDirs` to support custom installation dirs."John Ericson1-11/+9
Sorry for the disruption, I will try again later. This reverts commit efeb50197091b2ade24c00b9d55814bc433a7fd1.
2022-01-15[cmake] Use `GNUInstallDirs` to support custom installation dirs.John Ericson1-9/+11
This is the original patch in my GNUInstallDirs series, now last to merge as the final piece! It arose as a new draft of D28234. I initially did the unorthodox thing of pushing to that when I wasn't the original author, but since I ended up - Using `GNUInstallDirs`, rather than mimicking it, as the original author was hesitant to do but others requested. - Converting all the packages, not just LLVM, effecting many more projects than LLVM itself. I figured it was time to make a new revision. I have used this patch series (and many back-ports) as the basis of https://github.com/NixOS/nixpkgs/pull/111487 for my distro (NixOS), which was merged last spring (2021). It looked like people were generally on board in D28234, but I make note of this here in case extra motivation is useful. --- As pointed out in the original issue, a central tension is that LLVM already has some partial support for these sorts of things. Variables like `COMPILER_RT_INSTALL_PATH` have already been dealt with. Variables like `LLVM_LIBDIR_SUFFIX` however, will require further work, so that we may use `CMAKE_INSTALL_LIBDIR`. These remaining items will be addressed in further patches. What is here is now rote and so we should get it out of the way before dealing more intricately with the remainder. Reviewed By: #libunwind, #libc, #libc_abi, compnerd Differential Revision: https://reviews.llvm.org/D99484
2022-01-14[Polly][CMake] Make PollyConfig.cmake relocatable like other projects'John Ericson2-12/+23
This builds on D116521 to add this functionality to Polly without more copy-pasted code. Reviewed By: beanz Differential Revision: https://reviews.llvm.org/D116555
2020-09-15[Windows][Polly] Disable LLVMPolly module for all compilers on WindowsMateusz Mikuła1-1/+1
Before this patch, the cmake disabled loadable modules when compiling with Visual Studio. However, the reason for this is a limitation of the Windows DLLs, thus this restriction should apply to any compiler for the Windows platform, such as MinGW, Cygwin, icc, etc. Differential Revision: https://reviews.llvm.org/D87524
2020-09-07[CMake][Polly] Remove dead CMake codeRaul Tambre1-15/+0
LLVM requires CMake 3.13.4 so remove code behind checks for an older version. Reviewed By: phosek Differential Revision: https://reviews.llvm.org/D87192
2020-08-27[polly][cmake] Don't build LLVMPolly.so without PICRainer Orth1-2/+2
A build on `sparcv9-sun-solaris2.11` with `-DLLVM_ENABLE_PIC=Off` failed linking `LLVMPolly.so`: [2277/2297] Linking CXX shared module lib/LLVMPolly.so FAILED: lib/LLVMPolly.so [...] ld: fatal: relocation error: R_SPARC_H44: file tools/polly/lib/CMakeFiles/obj.Polly.dir/Analysis/DependenceInfo.cpp.o: symbol .data._ZL16__gthread_active (section): invalid shared object relocation type: ABS44 code model unsupported [...] As on many other targets, one cannot link non-PIC objects into a shared object on Solaris/sparcv9. The following patch avoids this by not building the library without PIC. It allowed the build to finish. Differential Revision: https://reviews.llvm.org/D85627
2020-01-07[cmake] Use source-groups in Polly.Christopher Tetreault1-0/+25
Configure CMake to setup source-groups for Polly. Source groups describe how source files should be organized in IDEs. By default, all headers are dumped into one folder under PollyCore and all source files into another. On disk, these files are organized into folders, but this isn't reflected in the IDE. This change uses CMake source groups to have the IDE reflect the on disk layout. This will make it easier to visualize the project structure for users of Visual Studio and XCode Patch by Christopher Tetreault <ctetreau@quicinc.com> Reviewed By: Meinersbur, grosser Differential Revision: https://reviews.llvm.org/D72117
2018-11-06[CMake] Fix generation of exported targets in build directoryPhilip Pfaffe1-2/+2
CMake generates the exports file wrongly if the CMAKE_BUILD_TYPE is unset for multi-configuration generators. The generated file lib/cmake/polly/PollyExports-all.cmake then contains: set_target_properties(LLVMPolly PROPERTIES IMPORTED_LOCATION_ my_build_dir/lib/LLVMPolly.so) set_target_properties(Polly PROPERTIES IMPORTED_LOCATION_ my_build_dir/lib/libPolly.a) This patch conditionalizes the underscore. Patch by: Marcin Copik Differential Revision: D53376 llvm-svn: 346231
2018-08-01[JSONExporter] Replace bundled Jsoncpp with llvm/Support/JSON.h. NFC.Michael Kruse2-59/+0
Differential Revision: https://reviews.llvm.org/D49950 llvm-svn: 338461
2018-01-12[CMake] Use only keyword-version of target_link_library. NFC.Michael Kruse1-2/+2
CMake insists that for each target, one uses only the non-keyword version of target_link_library target_link_library(mytarget lib) or the one with PUBLIC/PRIVATE/INTERFACE keyword: target_link_library(mytarget PUBLIC lib) Otherwise, CMake fails with the error message: The keyword signature for target_link_libraries has already been used with the target "mytarget". All uses of target_link_libraries with a target must be either all-keyword or all-plain. Change all occurances of target_link_library to the newer keyworded version to avoid such errors. Some already have been changed in r319840, but might not be sufficient for all build configurations to build the doxygen manual. Reported-by: Tanya Lattner <tanyalattner@llvm.org> llvm-svn: 322376
2017-07-18[CMake] FindJsoncpp.cmake: Use descriptive variable name for libjsoncpp.so path.Michael Kruse1-3/+3
find_library(lib) stores the result in the variable "lib", which is also cached in CMakeCache.txt. This could theoretically conflict if jsoncpp required two libraries, which each would get cached as "lib". Use a more descriptive and disambiguative "jsoncpp_${libname}" for that. llvm-svn: 308289
2017-07-18[CMake] FindJsoncpp.cmake: Use foreach variable.Michael Kruse1-1/+1
Use ${libname} instead of ${lib}. By a coincidence, this worked because ${lib} also the variable used for finding the libjsoncpp.so full path. llvm-svn: 308288
2017-07-18[CMake] FindJsoncpp.cmake: search pkg-config libs in default search paths.Michael Kruse1-1/+0
pkg_search_module(JSONCPP) should set JSONCPP_LIBDIR/JSONCPP_LIBRARY_DIRS to where the libjsoncpp.so can be found. However, on Ubuntu 14.04 LTS (Trusty Tahr) it returns /usr/lib while the libjsoncpp library can be found at /usr/lib/x86_64-linux-gnu/libjsoncpp.so. Thus, while searching for the full path of the jsoncpp library, it is not found. JSONCPP_LIBDIR is correctly set to /usr/lib/x86_64-linux-gnu on e.g., Ubuntu 16.04 LTS (Xenial Xerus ) Fix by removing the NO_DEFAULT_PATH flag, in order to search the system default paths even if the library is not found in JSONCPP_LIBDIR/JSONCPP_LIBRARY_DIRS. This fixes bug llvm.org/PR33798. llvm-svn: 308287
2017-07-11[Polly][CMake] Use the CMake Package instead of llvm-config in out-of-tree ↵Philip Pfaffe1-5/+0
builds Summary: As of now, Polly uses llvm-config to set up LLVM dependencies in an out-of-tree build. This is problematic for two reasons: 1) Right now, in-tree and out-of-tree builds in fact do different things. E.g., in an in-tree build, libPolly depends on a handful of LLVM libraries, while in an out-of-tree build it depends on all of them. This means that we often need to treat both paths seperately. 2) I'm specifically unhappy with the way libPolly is linked right now, because it just blindly links against all the LLVM libs. That doesn't make a lot of sense. For instance, one of these libs is LLVMTableGen, which contains a command line definition of a -o option. This means that I can not link an out-of-tree libPolly into a tool which might want to offer a -o option as well. This patch (mostly) drop the use of llvm-config in favor of LLVMs exported cmake package. However, building Polly with unittests requires access to the gtest sources (in the LLVM source tree). If we're building against an LLVM installation, this source tree is unavailable and must specified. I'm using llvm-config to provide a default in this case. Reviewers: Meinersbur, grosser Reviewed By: grosser Subscribers: tstellar, bollu, chapuni, mgorny, pollydev, llvm-commits Differential Revision: https://reviews.llvm.org/D33299 llvm-svn: 307650
2017-06-29Test commitNAKAMURA Takumi1-1/+1
llvm-svn: 306696
2017-06-06[CMake] Retire Polly's FindCUDA.cmake in favour of CMake's default ↵Philip Pfaffe1-23/+0
FindCUDA.cmake script. Patch by: Singapuram Sanjay Reviewers: grosser, philip.pfaffe Reviewed By: philip.pfaffe Subscribers: pollydev, mgorny Tags: #polly Differential Revision: https://reviews.llvm.org/D33669 llvm-svn: 304818
2017-05-12[Polly][CMake] Fix variable name in target exportsPhilip Pfaffe1-1/+1
llvm-svn: 302888
2017-05-10[Polly][CMake] Fix syntactical errors in the exported configPhilip Pfaffe1-2/+2
llvm-svn: 302657
2017-05-06[CMake] Introduce POLLY_BUNDLED_JSONCPP.Michael Kruse2-0/+60
Allow using a system's install jsoncpp library instead of the bundled one with the setting POLLY_BUNDLED_JSONCPP=OFF. This fixes llvm.org/PR32929 Differential Revision: https://reviews.llvm.org/D32922 llvm-svn: 302336
2017-04-27[Polly][Cmake] Add missing include paths to exported cmake configPhilip Pfaffe1-3/+13
llvm-svn: 301552
2017-03-09[Cmake] Generate a PollyConfig.cmake.Michael Kruse2-0/+169
Generate a PollyConfig.cmake for use with Cmake's find_package in out-of-tree projects. Contributed-by: Philip Pfaffe <philip.pfaffe@gmail.com> Differential Revision: https://reviews.llvm.org/D30495 llvm-svn: 297395
2017-02-27[Cmake] Optionally use a system isl version.Michael Kruse1-0/+24
This patch adds an option to build against a version of libisl already installed on the system. The installation is autodetected using the pkg-config file shipped with isl. The detection of the library is in the FindISL.cmake module that creates an imported target. Contributed-by: Philip Pfaffe <philip.pfaffe@gmail.com> Differential Revision: https://reviews.llvm.org/D30043 llvm-svn: 296361
2016-09-12Remove -fvisibility=hidden and FORCE_STATIC.Michael Kruse1-7/+1
The flag -fvisibility=hidden flag was used for the integrated Integer Set Library (and PPCG) to keep their definitions local to Polly. The motivation was the be loaded into a DragonEgg-powered GCC, where GCC might itself use ISL for its Graphite extension. The symbols of Polly's ISL and GCC's ISL would clash. The DragonEgg project is not actively developed anymore, but Polly's unittests need to call ISL functions to set up a testing environment. Unfortunately, the -fvisibility=hidden flag means that the ISL symbols are not available to the gtest executable as it resides outside of libPolly when linked dynamically. Currently, CMake links a second copy of ISL into the unittests which leads to subtle bugs. What got observed is that two isl_ids for isl_id_none exist, one for each library instance. Because isl_id's are compared by address, isl_id_none could happen to be different from isl_id_none, depending on which library instance set the address and does the comparison. Also remove the FORCE_STATIC flag which was introduced to keep the ISL symbols visible inside the same libPolly shared object, even when build with BUILD_SHARED_LIBS. Differential Revision: https://reviews.llvm.org/D24460 llvm-svn: 281242
2016-08-25Add missing words to wanrning.Michael Kruse1-1/+1
llvm-svn: 279738
2016-08-25Add warning for FORCE_STATIC libraries when using BUILD_SHARED_LIBS.Michael Kruse1-0/+4
We cannot built ISL as shared object because we build it with -fvisibility=hidden; The created shared object would have no accessible symbols. The reason it is built with -fvisibility=hidden is because opt/clang might load other libraries that have ISL embedded and whose' symbols would conflict with Polly's private ISL. This could happend with Draggonegg. In the future we might instead statically link PollyISL into the Polly shared object to avoid installing the static library. Requested-by: Vedran Miletic <vedran@miletic.net> See-also: llvm.org/PR27306 llvm-svn: 279737
2016-06-21Respect LLVM_INSTALL_TOOLCHAIN_ONLY.Eugene Zelenko1-4/+6
Only shared library should be installed when LLVM_INSTALL_TOOLCHAIN_ONLY=ON. Differential revision: http://reviews.llvm.org/D21543 llvm-svn: 273292
2016-04-09Fix: Always honor LLVM_LIBDIR_SUFFIX.Michael Kruse1-1/+1
Static libraries where installed into "lib${LLVM_LIBDIR_SUFFIX}" while shared ones into "lib". I found no justification for this behaviour. This patch changes both types of libraries to be install into "lib${LLVM_LIBDIR_SUFFIX}". LLVM and clang use the same behaviour. This fixes llvm.org/PR27305. llvm-svn: 265872
2015-09-24Compile ISL into its own libraryMichael Kruse1-1/+6
Refactor all ISL-related cmake build instructions into its own CMakeLists.txt and build as a separate library. This is useful to apply ISL-related build flags to ISL only and not to Polly's files. Also, it the separation of both projects becomes clearer. Proposed name of the library is Polly_isl. It is not "isl" to avoid mix-up with potentially installed libisl.{a|so}. Tested configurations: - Windows with cmake 3.2 - Ubuntu with cmake 3.0.2 - Ubuntu with cmake 3.0.2 BUILD_SHARED_LIBS on - Ubuntu with cmake 2.8.12.2 (LLVM minimum version) - Ubuntu out-of-LLVM-tree Differential Revision: http://reviews.llvm.org/D12810 llvm-svn: 248484
2015-07-21Unify FOLDER property of Polly targetsMichael Kruse1-0/+3
Put all Polly targets into a single "Polly" category (i.e. solution folder). Previously there was no recognizable scheme and most categories contained just one or two targets or targets didn't belong to any category. Reviewers: grosser llvm-svn: 242779
2015-07-21Remove /Za flag from Visual Studio compilationMichael Kruse1-8/+0
According to Stephan T. Lavavej it is broken. See http://comments.gmane.org/gmane.comp.compilers.clang.devel/21638 Reviewers: grosser llvm-svn: 242773
2015-06-29[Polly] Add -std=c99 flag only to C source filesMichael Kruse1-2/+7
Summary: Adding the flag to C++ source files emits a warning, hence we set the compile flag depending on the file's language. Reviewers: grosser Subscribers: Meinersbur, pollydev, llvm-commits Projects: #polly Differential Revision: http://reviews.llvm.org/D10809 llvm-svn: 240986
2015-06-22Use C99 to compile ISLMichael Kruse1-0/+10
ISL with small integer optimization requires C99 to compile. gcc < 5.0 still uses C89 as default, so we need to enable the options to compile in C99 mode. This patch is preparing the actual activation of small integer optimization. Differential version: http://reviews.llvm.org/D10610 Reviewers: grosser llvm-svn: 240322
2015-03-30Drop libpluto supportTobias Grosser1-19/+0
We do not have buildbots or anything that tests this functionality, hence it most likely bitrots. People interested to use this functionality can always recover it from svn history. llvm-svn: 233570
generated by cgit v1.1 at 2024-09-18 04:33:11 +0000