summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Support/CRC.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Revert abb00753 "build: reduce CMake handling for zlib" (PR44780)Hans Wennborg2020-03-031-1/+1
| | | | | | | | | | | | | 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)
* Make llvm::crc32() work also for input sizes larger than 32 bits.Hans Wennborg2020-02-061-1/+9
| | | | | | | | | | | | The problem was noticed by the Chrome OS toolchain folks (crbug.com/1048445) because llvm-objcopy --add-gnu-debuglink would insert the wrong checksum when processing a binary larger than 4 GB. That use case regressed in 1e1e3ba2526 when we started using llvm::crc32() in more places. Differential revision: https://reviews.llvm.org/D74039 (cherry picked from commit 6c4a8bc0a9f6a466d90d542bef66d69550c1b041)
* build: reduce CMake handling for zlibSaleem Abdulrasool2020-01-021-1/+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. 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/+1
| | | | | | | 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.
* build: reduce CMake handling for zlibSaleem Abdulrasool2020-01-011-1/+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.
* Unify the two CRC implementationsHans Wennborg2019-10-091-41/+72
| | | | | | | | | | | | | | | | | | | | | 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
* Attempt to recommit r357901Eugene Leviant2019-04-081-0/+68
| | | | llvm-svn: 357905
* Reverting r357901 as fails to build on some of the buildbotsEugene Leviant2019-04-081-68/+0
| | | | llvm-svn: 357902
* [Support] Add zlib independent CRC32Eugene Leviant2019-04-081-0/+68
Differential revision: https://reviews.llvm.org/D59816 llvm-svn: 357901
OpenPOWER on IntegriCloud