bcm5719-llvm - Project Ortega BCM5719 LLVM

	Commit message (Collapse)	Author	Age	Files	Lines
*	Make llvm::crc32() work also for input sizes larger than 32 bits.	Hans Wennborg	2020-02-06	1	-0/+20
\| \| \| \| \| \| \| \| \| \| \| \|	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)
*	Unify the two CRC implementations	Hans Wennborg	2019-10-09	1	-4/+19
\| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \|	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 r357901	Eugene Leviant	2019-04-08	1	-0/+29
\| \| \| \|	llvm-svn: 357905
*	Reverting r357901 as fails to build on some of the buildbots	Eugene Leviant	2019-04-08	1	-29/+0
\| \| \| \|	llvm-svn: 357902
*	[Support] Add zlib independent CRC32	Eugene Leviant	2019-04-08	1	-0/+29
	Differential revision: https://reviews.llvm.org/D59816 llvm-svn: 357901