[LLVMdev] [lld] contentHash in the Reader ?

[Chandler Carruth]

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.


>
>>
>> Thanks
>>
>> 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...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130508/ff705a02/attachment.html>