summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Support/CMakeLists.txt
Commit message (Collapse)AuthorAgeFilesLines
* Revert abb00753 "build: reduce CMake handling for zlib" (PR44780)Hans Wennborg2020-03-031-26/+5
| | | | | | | | | | | | | and follow-ups: a2ca1c2d "build: disable zlib by default on Windows" 2181bf40 "[CMake] Link against ZLIB::ZLIB" 1079c68a "Attempt to fix ZLIB CMake logic on Windows" This changed the output of llvm-config --system-libs, and more importantly it broke stand-alone builds. Instead of piling on more fix attempts, let's revert this to reduce the risk of more breakages. (cherry picked from commit 916be8fd6a0a0feea4cefcbeb0c22c65848d7a2e)
* Attempt to fix ZLIB CMake logic on WindowsReid Kleckner2020-03-021-2/+4
| | | | | | CMake doesn't seem to like it when you regex search for "^". (cherry picked from commit 1079c68aa0fdb14d270a31c0df49a2afc5ed2485)
* [CMake] Link against ZLIB::ZLIBPetr Hosek2020-03-021-3/+22
| | | | | | | | This is the imported target that find_package(ZLIB) defines. Differential Revision: https://reviews.llvm.org/D74176 (cherry picked from commit 2181bf40d87165ff4c208b46b135be823eef5c55)
* build: reduce CMake handling for zlibSaleem Abdulrasool2020-01-021-3/+3
| | | | | | | | | | | | | Rather than handling zlib handling manually, use `find_package` from CMake to find zlib properly. Use this to normalize the `LLVM_ENABLE_ZLIB`, `HAVE_ZLIB`, `HAVE_ZLIB_H`. Furthermore, require zlib if `LLVM_ENABLE_ZLIB` is set to `YES`, which requires the distributor to explicitly select whether zlib is enabled or not. This simplifies the CMake handling and usage in the rest of the tooling. This restores 68a235d07f9e7049c7eb0c8091f37e385327ac28, e6c7ed6d2164a0659fd9f6ee44f1375d301e3cad. The problem with the windows bot is a need for clearing the cache.
* Revert "build: reduce CMake handling for zlib"James Henderson2020-01-021-1/+4
| | | | | | | This reverts commit 68a235d07f9e7049c7eb0c8091f37e385327ac28. This commit broke the clang-x64-windows-msvc build bot and a follow-up commit did not fix it. Reverting to fix the bot.
* Revert "build: make `LLVM_ENABLE_ZLIB` a tri-bool for users"James Henderson2020-01-021-4/+1
| | | | | | | This reverts commit e6c7ed6d2164a0659fd9f6ee44f1375d301e3cad. This commit was an attempt to fix the build bots, but it still left the clang-x64-windows-msvc bot in a broken state.
* build: make `LLVM_ENABLE_ZLIB` a tri-bool for usersSaleem Abdulrasool2020-01-011-1/+4
| | | | | | Treat the flag `LLVM_ENABLE_ZLIB` as a tri-bool, `FORCE_ON` being `ON`, and `ON` being an auto-detect. This is needed as many of the builders enable the flag without having zlib available.
* build: reduce CMake handling for zlibSaleem Abdulrasool2020-01-011-4/+1
| | | | | | | | | Rather than handling zlib handling manually, use `find_package` from CMake to find zlib properly. Use this to normalize the `LLVM_ENABLE_ZLIB`, `HAVE_ZLIB`, `HAVE_ZLIB_H`. Furthermore, require zlib if `LLVM_ENABLE_ZLIB` is set to `YES`, which requires the distributor to explicitly select whether zlib is enabled or not. This simplifies the CMake handling and usage in the rest of the tooling.
* [cmake] Explicitly mark libraries defined in lib/ as "Component Libraries"Tom Stellard2019-11-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Most libraries are defined in the lib/ directory but there are also a few libraries defined in tools/ e.g. libLLVM, libLTO. I'm defining "Component Libraries" as libraries defined in lib/ that may be included in libLLVM.so. Explicitly marking the libraries in lib/ as component libraries allows us to remove some fragile checks that attempt to differentiate between lib/ libraries and tools/ libraires: 1. In tools/llvm-shlib, because llvm_map_components_to_libnames(LIB_NAMES "all") returned a list of all libraries defined in the whole project, there was custom code needed to filter out libraries defined in tools/, none of which should be included in libLLVM.so. This code assumed that any library defined as static was from lib/ and everything else should be excluded. With this change, llvm_map_components_to_libnames(LIB_NAMES, "all") only returns libraries that have been added to the LLVM_COMPONENT_LIBS global cmake property, so this custom filtering logic can be removed. Doing this also fixes the build with BUILD_SHARED_LIBS=ON and LLVM_BUILD_LLVM_DYLIB=ON. 2. There was some code in llvm_add_library that assumed that libraries defined in lib/ would not have LLVM_LINK_COMPONENTS or ARG_LINK_COMPONENTS set. This is only true because libraries defined lib lib/ use LLVMBuild.txt and don't set these values. This code has been fixed now to check if the library has been explicitly marked as a component library, which should now make it easier to remove LLVMBuild at some point in the future. I have tested this patch on Windows, MacOS and Linux with release builds and the following combinations of CMake options: - "" (No options) - -DLLVM_BUILD_LLVM_DYLIB=ON - -DLLVM_LINK_LLVM_DYLIB=ON - -DBUILD_SHARED_LIBS=ON - -DBUILD_SHARED_LIBS=ON -DLLVM_BUILD_LLVM_DYLIB=ON - -DBUILD_SHARED_LIBS=ON -DLLVM_LINK_LLVM_DYLIB=ON Reviewers: beanz, smeenai, compnerd, phosek Reviewed By: beanz Subscribers: wuzish, jholewinski, arsenm, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, nhaehnle, mgorny, mehdi_amini, sbc100, jgravelle-google, hiraditya, aheejin, fedor.sergeev, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, steven_wu, rogfer01, MartinMosbeck, brucehoult, the_o, dexonsmith, PkmX, jocewei, jsji, dang, Jim, lenary, s.egerton, pzheng, sameer.abuasal, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70179
* Remove Support/Options.h, it is unusedReid Kleckner2019-11-151-1/+0
| | | | | | | | | | | | | | | | | It was added in 2014 in 732e0aa9fb84f1 with one use in Scalarizer.cpp. That one use was then removed when porting to the new pass manager in 2018 in b6f76002d9158628e78. While the RFC and the desire to get off of static initializers for cl::opt all still stand, this code is now dead, and I think we should delete this code until someone is ready to do the migration. There were many clients of CommandLine.h that were it transitively through LLVMContext.h, so I cleaned that up in 4c1a1d3cf97e1ede466. Reviewers: beanz Differential Revision: https://reviews.llvm.org/D70280
* Unify the two CRC implementationsHans Wennborg2019-10-091-1/+0
| | | | | | | | | | | | | | | | | | | | | David added the JamCRC implementation in r246590. More recently, Eugene added a CRC-32 implementation in r357901, which falls back to zlib's crc32 function if present. These checksums are essentially the same, so having multiple implementations seems unnecessary. This replaces the CRC-32 implementation with the simpler one from JamCRC, and implements the JamCRC interface in terms of CRC-32 since this means it can use zlib's implementation when available, saving a few bytes and potentially making it faster. JamCRC took an ArrayRef<char> argument, and CRC-32 took a StringRef. This patch changes it to ArrayRef<uint8_t> which I think is the best choice, and simplifies a few of the callers nicely. Differential revision: https://reviews.llvm.org/D68570 llvm-svn: 374148
* Move LLVM_ENABLE_ABI_BREAKING_CHECKS variables to their own fileEric Christopher2019-09-101-0/+1
| | | | | | | | | | | | | so that you don't have to link Error.o and all of its dependencies. In more detail: global initializers in Error.o can't be elided with -ffunction-sections/-gc-sections since they always need to be run causing a fairly significant binary bloat if all you want is the ABI breaking checks code. Differential Revision: https://reviews.llvm.org/D67387 llvm-svn: 371561
* [Support] Re-introduce the RWMutexImpl for macOS < 10.12Jonas Devlieghere2019-08-151-0/+1
| | | | | | | | | | | | | In r369018, Benjamin replaced the custom RWMutex implementation with their C++14 counterpart. Unfortunately, std::shared_timed_mutex is only available on macOS 10.12 and later. This prevents LLVM from compiling even on newer versions of the OS when you have an older deployment target. This patch reintroduced the old RWMutexImpl but guards it by the macOS availability macro. Differential revision: https://reviews.llvm.org/D66313 llvm-svn: 369064
* [Support] Base RWMutex on std::shared_timed_mutex (C++14)Benjamin Kramer2019-08-151-1/+0
| | | | | | | | This should have the same semantics. We use std::shared_mutex instead on MSVC and C++17, std::shared_timed_mutex is less efficient than our custom implementation on Windows, std::shared_mutex should be faster. llvm-svn: 369018
* [Support] Base SmartMutex on std::recursive_mutexBenjamin Kramer2019-08-071-1/+0
| | | | | | | | | | | - Remove support for non-recursive mutexes. This was unused. - The std::recursive_mutex is now created/destroyed unconditionally. Locking is still only done if threading is enabled. - Alias SmartScopedLock to std::lock_guard. This should make no semantic difference on the existing APIs. llvm-svn: 368158
* [Support] move FileCollector from LLDB to llvm/SupportAlex Lorenz2019-07-241-0/+1
| | | | | | | | | The file collector class is useful for creating reproducers, not just for LLDB, but for other tools as well in LLVM/Clang. Differential Revision: https://reviews.llvm.org/D65237 llvm-svn: 366956
* Attempt to recommit r357901Eugene Leviant2019-04-081-0/+1
| | | | llvm-svn: 357905
* Reverting r357901 as fails to build on some of the buildbotsEugene Leviant2019-04-081-1/+0
| | | | llvm-svn: 357902
* [Support] Add zlib independent CRC32Eugene Leviant2019-04-081-0/+1
| | | | | | Differential revision: https://reviews.llvm.org/D59816 llvm-svn: 357901
* Adds `-ftime-trace` option to clang that produces Chrome `chrome://tracing` ↵Anton Afanasyev2019-03-301-0/+1
| | | | | | | | | | | | | | compatible JSON profiling output dumps. This change adds hierarchical "time trace" profiling blocks that can be visualized in Chrome, in a "flame chart" style. Each profiling block can have a "detail" string that for example indicates the file being processed, template name being instantiated, function being optimized etc. This is taken from GitHub PR: https://github.com/aras-p/llvm-project-20170507/pull/2 Patch by Aras Pranckevičius. Differential Revision: https://reviews.llvm.org/D58675 llvm-svn: 357340
* Moved everything SMT-related to LLVM and updated the cmake scripts.Mikhail R. Gadelha2019-03-251-1/+16
| | | | | | Differential Revision: https://reviews.llvm.org/D54978 llvm-svn: 356929
* Annotate timeline in Instruments with passes and other timed regions.Daniel Sanders2019-02-191-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* This reverts commit 1440a848a635849b97f7a5cfa0ecc40d37451f5b.Mikhail R. Gadelha2019-02-091-16/+1
| | | | | | | | and commit a1853e834c65751f92521f7481b15cf0365e796b. They broke arm and aarch64 llvm-svn: 353590
* Move the SMT API to LLVMMikhail R. Gadelha2019-02-071-1/+16
| | | | | | | | Moved everything SMT-related to LLVM and updated the cmake scripts. Differential Revision: https://reviews.llvm.org/D54978 llvm-svn: 353373
* [ADT] Add streaming operators for llvm::OptionalPavel Labath2019-01-181-0/+1
| | | | | | | | | | | | | | | | | | | | | | | Summary: The operators simply print the underlying value or "None". The trickier part of this patch is making sure the streaming operators work even in unit tests (which was my primary motivation, though I can also see them being useful elsewhere). Since the stream operator was a template, implicit conversions did not kick in, and our gtest glue code was explicitly introducing an implicit conversion to make sure other implicit conversions do not kick in :P. I resolve that by specializing llvm_gtest::StreamSwitch for llvm:Optional<T>. Reviewers: sammccall, dblaikie Reviewed By: sammccall Subscribers: mgorny, dexonsmith, kristina, llvm-commits Differential Revision: https://reviews.llvm.org/D56795 llvm-svn: 351548
* [ARM, AArch64] Move ARM/AArch64 target parsers intoDavid Spickett2018-11-281-0/+2
| | | | | | | | | | | | | | | | | separate files to enable future changes. This moves ARM and AArch64 target parsing into their own files. They are still accessible through TargetParser.h as before. Several functions in AArch64 which were just forwarders to ARM have been removed. All except AArch64::getFPUName were unused, and that was only used in a test. Which itself was overlapping one in ARM, so it has also been removed. Differential revision: https://reviews.llvm.org/D53980 llvm-svn: 347741
* Move BuryPointer from Clang to LLVM for use in other LLVM toolsDavid Blaikie2018-11-171-0/+1
| | | | | | | Specifically planning to use this in llvm-symbolizer to remove the cost of cleanup there. llvm-svn: 347140
* Lift VFS from clang to llvm (NFC)Jonas Devlieghere2018-10-101-0/+1
| | | | | | | | | | | | | | | | | | | This patch moves the virtual file system form clang to llvm so it can be used by more projects. Concretely the patch: - Moves VirtualFileSystem.{h|cpp} from clang/Basic to llvm/Support. - Moves the corresponding unit test from clang to llvm. - Moves the vfs namespace from clang::vfs to llvm::vfs. - Formats the lines affected by this change, mostly this is the result of the added llvm namespace. RFC on the mailing list: http://lists.llvm.org/pipermail/llvm-dev/2018-October/126657.html Differential revision: https://reviews.llvm.org/D52783 llvm-svn: 344140
* Common infrastructure for reading a profile remapping file and buildingRichard Smith2018-09-131-0/+1
| | | | | | | | a mangling remapper from it. Differential Revision: https://reviews.llvm.org/D51246 llvm-svn: 342161
* [cmake] Speed up check-llvm 5x by delay loading shell32 and ole32Reid Kleckner2018-09-111-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Previously, check-llvm on my Windows 10 workstation took about 300s to run, and it would lock up my mouse. Now, it takes just under 60s. Previously running the tests only used about 15% of the available CPU time, now it uses up to 60%. Shell32.dll and ole32.dll have direct dependencies on user32.dll and gdi32.dll. These DLLs are mostly used to for Windows GUI functionality, which most LLVM tools don't need. It seems that these DLLs acquire and release some system resources on startup and exit, and that requires acquiring the same highly contended lock discussed in this post: https://randomascii.wordpress.com/2017/07/09/24-core-cpu-and-i-cant-move-my-mouse/ Most LLVM tools still have a transitive dependency on SHGetKnownFolderPathW, which is used to look up the user home directory and local AppData directory. We also use SHFileOperationW to recursively delete a directory, but only LLDB and clang-doc use this today. At some point, we might consider removing these last shell32.dll deps, but for now, I would like to take this free performance. Many thanks to Bruce Dawson for suggesting this fix. He looked at an ETW trace of an LLVM test run, noticed these DLLs, and suggested avoiding them. Reviewers: zturner, pcc, thakis Subscribers: mgorny, llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D51952 llvm-svn: 342002
* Add data structure to form equivalence classes of mangled names.Richard Smith2018-08-241-0/+1
| | | | | | | | | | | | | | | Summary: Given a set of equivalent name fragments, this mechanism determines whether two mangled names are equivalent. The intent is to use this for fuzzy matching of profile data against the program after certain refactorings are performed. Reviewers: erik.pilkington, dlj Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D50935 llvm-svn: 340663
* Refactor FileCheck to make it usable as an APIAditya Nandakumar2018-08-071-0/+1
| | | | | | | | | | https://reviews.llvm.org/D50283 reviewed by bogner This patch refactors FileCheck's implementation into support so it can be used from C++ in other places (Unit tests). llvm-svn: 339192
* Lift JSON library from clang-tools-extra/clangd to llvm/Support.Sam McCall2018-07-091-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This consists of four main parts: - an type json::Expr representing JSON values of dynamic kind, which can be composed, inspected, and modified - a JSON parser from string -> json::Expr - a JSON printer from json::Expr -> string, with optional pretty-printing - a convention for mapping json::Expr <=> native types (fromJSON/toJSON) Mapping functions are provided for primitives (e.g. int, vector) and the ObjectMapper helper helps implement fromJSON for struct/object types. Based on clangd's usage, a couple of places I'd appreciate review attention: - fromJSON returns only bool. A richer error-signaling mechanism may be useful to provide useful messages, or let recursive fromJSONs (containers/structs) do careful error recovery. - should json::obj be always explicitly written (like json::ary) - there's no streaming parse API. I suspect there are some simple wins like a callback API where the document is a long array, and each element is small. But this can probably be bolted on easily when we see the need. Reviewers: bkramer, labath Subscribers: mgorny, ilya-biryukov, ioeric, MaskRay, llvm-commits Differential Revision: https://reviews.llvm.org/D45753 llvm-svn: 336534
* Move VersionTuple from clang/Basic to llvm/SupportPavel Labath2018-06-111-0/+1
| | | | | | | | | | | | | | | | | | | | | | | Summary: This kind of functionality is useful to other project apart from clang. LLDB works with version numbers a lot, but it does not have a convenient abstraction for this. Moving this class to a lower level library allows it to be freely used within LLDB. Since this class is used in a lot of places in clang, and it used to be in the clang namespace, it seemed appropriate to add it to the list of adopted classes in LLVM.h to avoid prefixing all uses with "llvm::". Also, I didn't find any tests specific for this class, so I wrote a couple of quick ones for the more interesting bits of functionality. Reviewers: zturner, erik.pilkington Subscribers: mgorny, cfe-commits, llvm-commits Differential Revision: https://reviews.llvm.org/D47887 llvm-svn: 334399
* [Support] Link libzircon.so when building LLVM for FuchsiaPetr Hosek2018-06-071-0/+3
| | | | | | | | This is necessary for zx_* symbols. Differential Revision: https://reviews.llvm.org/D47848 llvm-svn: 334232
* Define InitLLVM to do common initialization all at once.Rui Ueyama2018-04-131-0/+1
| | | | | | | | | | | We have a few functions that virtually all command wants to run on process startup/shutdown. This patch adds InitLLVM class to do that all at once, so that we don't need to copy-n-paste boilerplate code to each llvm command's main() function. Differential Revision: https://reviews.llvm.org/D45602 llvm-svn: 330046
* [Support] Move syntax highlighting into supportJonas Devlieghere2018-03-091-0/+1
| | | | | | | | | | | | Move the DWARF syntax highlighting into support. This has several advantages, most notably that this makes the WithColor RAII wrapper available outside libDebugInfo. Furthermore, several projects all have their own code for handling colored output. This provides a place to centralize it. Differential revision: https://reviews.llvm.org/D44215 llvm-svn: 327108
* Fix llvm-config --system-libs output on FreeBSD and NetBSDDimitry Andric2018-02-281-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: For various reasons, CMake's detection mechanism for `backtrace()` returns an absolute path `/usr/lib/libexecinfo.so` on FreeBSD and NetBSD. Since `tools/llvm-config/CMakeLists.txt` only checks if system libraries start with `-`, this causes `llvm-config --system-libs` to produce the following incorrect output: ``` -lrt -l/usr/lib/libexecinfo.so -ltinfo -lpthread -lz -lm ``` Fix it by removing the path and the `lib` prefix, to make it look like a regular short library name, suitable for appending to a `-l` link flag. This also fixes the `Bindings/Go/go.test` test case, since that always died with "unable to find library -l/usr/lib/libexecinfo.so". Reviewers: chandlerc, emaste, joerg, krytarowski Reviewed By: krytarowski Subscribers: hans, bdrewery, mgorny, hintonda, llvm-commits Differential Revision: https://reviews.llvm.org/D42702 llvm-svn: 326358
* llvm-config: Add advapi32 to --system-libs on Windows (PR36372)Hans Wennborg2018-02-231-1/+2
| | | | llvm-svn: 325894
* Resubmit r325107 (case folding DJB hash)Pavel Labath2018-02-211-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The issue was that the has function was generating different results depending on the signedness of char on the host platform. This commit fixes the issue by explicitly using an unsigned char type to prevent sign extension and adds some extra tests. The original commit message was: This patch implements a variant of the DJB hash function which folds the input according to the algorithm in the Dwarf 5 specification (Section 6.1.1.4.5), which in turn references the Unicode Standard (Section 5.18, "Case Mappings"). To achieve this, I have added a llvm::sys::unicode::foldCharSimple function, which performs this mapping. The implementation of this function was generated from the CaseMatching.txt file from the Unicode spec using a python script (which is also included in this patch). The script tries to optimize the function by coalescing adjecant mappings with the same shift and stride (terms I made up). Theoretically, it could be made a bit smarter and merge adjecant blocks that were interrupted by only one or two characters with exceptional mapping, but this would save only a couple of branches, while it would greatly complicate the implementation, so I deemed it was not worth it. Since we assume that the vast majority of the input characters will be US-ASCII, the folding hash function has a fast-path for handling these, and only whips out the full decode+fold+encode logic if we encounter a character outside of this range. It might be possible to implement the folding directly on utf8 sequences, but this would also bring a lot of complexity for the few cases where we will actually need to process non-ascii characters. Reviewers: JDevlieghere, aprantl, probinson, dblaikie Subscribers: mgorny, hintonda, echristo, clayborg, vleschuk, llvm-commits Differential Revision: https://reviews.llvm.org/D42740 llvm-svn: 325732
* Revert r325107 (case folding DJB hash) and subsequent build fixPavel Labath2018-02-141-1/+0
| | | | | | | The "knownValuesUnicode" test in the patch fails on ppc64 and arm64 bots. Reverting while I investigate. llvm-svn: 325115
* Implement a case-folding version of DJB hashPavel Labath2018-02-141-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch implements a variant of the DJB hash function which folds the input according to the algorithm in the Dwarf 5 specification (Section 6.1.1.4.5), which in turn references the Unicode Standard (Section 5.18, "Case Mappings"). To achieve this, I have added a llvm::sys::unicode::foldCharSimple function, which performs this mapping. The implementation of this function was generated from the CaseMatching.txt file from the Unicode spec using a python script (which is also included in this patch). The script tries to optimize the function by coalescing adjecant mappings with the same shift and stride (terms I made up). Theoretically, it could be made a bit smarter and merge adjecant blocks that were interrupted by only one or two characters with exceptional mapping, but this would save only a couple of branches, while it would greatly complicate the implementation, so I deemed it was not worth it. Since we assume that the vast majority of the input characters will be US-ASCII, the folding hash function has a fast-path for handling these, and only whips out the full decode+fold+encode logic if we encounter a character outside of this range. It might be possible to implement the folding directly on utf8 sequences, but this would also bring a lot of complexity for the few cases where we will actually need to process non-ascii characters. Reviewers: JDevlieghere, aprantl, probinson, dblaikie Subscribers: mgorny, hintonda, echristo, clayborg, vleschuk, llvm-commits Differential Revision: https://reviews.llvm.org/D42740 llvm-svn: 325107
* [Support] Move DJB hash to support. NFCJonas Devlieghere2018-01-281-0/+1
| | | | | | | | | | | This patch moves the DJB hash to support. This is consistent with other hashing algorithms living there. The hash is used by the DWARF accelerator tables. We're doing this now because the hashing function is needed by dsymutil and we don't want to link against libBinaryFormat. Differential revision: https://reviews.llvm.org/D42594 llvm-svn: 323616
* Re-commit "[cmake] Enable zlib support on windows"Pavel Labath2017-12-051-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | This recommits r319533 which was broken llvm-config --system-libs output. The reason was that I used find_libraries for searching for the z library. This returns absolute paths, and when these paths made it into llvm-config, it made it produce nonsensical flags. To fix this, I hand-roll a search for the library in the same way that we search for the terminfo library a couple of lines below. This is a bit less flexible than the find_library option, as it does not allow the user to specify the path to the library at configure time (which is important on windows, as zlib is unlikely to be found in any of the standard places cmake searches), but I was able to guide the build to find it with appropriate values of LIB and INCLUDE environment variables. Reviewers: compnerd, rnk, beanz, rafael Subscribers: llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D40779 llvm-svn: 319751
* Revert "[cmake] Enable zlib support on windows"Pavel Labath2017-12-041-3/+3
| | | | | | | | | | | | This reverts commit r319533 as it broke llvm-config --system-libs output and everything that depends on it (which is mostly out of tree or downstream folks, but includes a couple of llvm buildbots as well). I think I have a fix for this in D40779, but I want someone to look review it first. In the mean time, I am reverting this change, as it seems to break a lot of people. llvm-svn: 319663
* [cmake] Enable zlib support on windowsPavel Labath2017-12-011-3/+3
| | | | | | | | | | | | | | | | | | | | | | | Summary: zlib support was hard-wired to off for (non-cygwin) windows targets. This disables some features, such as reading debug info from compressed dwarf sections. This has been this way since zlib support was added in 2013 (r180083), but there is no obvious reason for that. Zlib is perfectly capable of being compiled for windows (it even has a cmake file that works out of the box). This enables one to turn on zlib support on windows, if one has zlib avaliable. Reviewers: rnk, beanz Subscribers: mgorny, aprantl, llvm-commits Differential Revision: https://reviews.llvm.org/D40655 llvm-svn: 319533
* [globalisel][tablegen] Generate rule coverage and use it to identify ↵Daniel Sanders2017-11-161-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | untested rules Summary: This patch adds a LLVM_ENABLE_GISEL_COV which, like LLVM_ENABLE_DAGISEL_COV, causes TableGen to instrument the generated table to collect rule coverage information. However, LLVM_ENABLE_GISEL_COV goes a bit further than LLVM_ENABLE_DAGISEL_COV. The information is written to files (${CMAKE_BINARY_DIR}/gisel-coverage-* by default). These files can then be concatenated into ${LLVM_GISEL_COV_PREFIX}-all after which TableGen will read this information and use it to emit warnings about untested rules. This technique could also be used by SelectionDAG and can be further extended to detect hot rules and give them priority over colder rules. Usage: * Enable LLVM_ENABLE_GISEL_COV in CMake * Build the compiler and run some tests * cat gisel-coverage-[0-9]* > gisel-coverage-all * Delete lib/Target/*/*GenGlobalISel.inc* * Build the compiler Known issues: * ${LLVM_GISEL_COV_PREFIX}-all must be generated as a manual step due to a lack of a portable 'cat' command. It should be the concatenation of all ${LLVM_GISEL_COV_PREFIX}-[0-9]* files. * There's no mechanism to discard coverage information when the ruleset changes Depends on D39742 Reviewers: ab, qcolombet, t.p.northover, aditya_nandakumar, rovka Reviewed By: rovka Subscribers: vsk, arsenm, nhaehnle, mgorny, kristof.beyls, javed.absar, igorb, llvm-commits Differential Revision: https://reviews.llvm.org/D39747 llvm-svn: 318356
* Revert 316150 which reinstated r316025.Vassil Vassilev2017-10-191-1/+1
| | | | | | It fails on some bots and now we know how to reproduce it. llvm-svn: 316153
* Reinstate r316025, reverted in r316029.Vassil Vassilev2017-10-191-1/+1
| | | | | | | | | | | | | | | Original commit message: "[cmake] Use find_package to discover zlib This allows us to use standard cmake utilities to point to non-system zlib locations. Patch by Oksana Shadura and me (D39002)." The new patch brings back the old behavior in the cases where find_package cannot find zlib. llvm-svn: 316150
* Revert "[cmake] Use find_package to discover zlib"Vassil Vassilev2017-10-171-1/+1
| | | | | | We are investigating what went wrong. llvm-svn: 316029
OpenPOWER on IntegriCloud