[LLVMdev] [lld] contentHash in the Reader ?
chandlerc at google.com
Wed May 8 10:50:46 PDT 2013
On Wed, May 8, 2013 at 7:33 PM, Rui Ueyama <ruiu at google.com> wrote:
> On Wed, May 8, 2013 at 10:29 AM, Shankar Easwaran <shankare at codeaurora.org
> > wrote:
>> On 5/8/2013 11:35 AM, Chandler Carruth wrote:
>>> Interestingly newer, supposedly "more secure" digest algorithms are also
>>> very often significantly faster. I don't think we want any of the ones
>>> mentioned here, I think we want one of the candidates is the SHA3
>>> competition which had truly stellar software implementation throughput. I'm
>>> hoping to add support for such a digest algorithm to LLVM soon, as there
>>> are many folks who want to consume this information: modules, merge
>>> function pass, debug info, and the linker.
>> Nice, Is it performant in size as well as speed too ?. Because lld would
>> need to store this information for every atom thats mergeable.
> How about using only the first 80 (or 96 or 128) bits of the digest?
This is exactly the right pattern (although the chunk size is usually 32,
64, 128, 256, 512). You trade off collision resistance against space. I
think for atoms, you want to burn space in order to *not* compare them at
all. I would suggest storing 256 bits at least.
>> What are the SHA-3 variants that you think would suite these needs ?
I want to look at the implementation complexity. The winner (and the
official SHA3 algorithm), BMW and Skein are all worth looking at.
>> Shankar Easwaran
>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
>> by the Linux Foundation
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev