[LLVMdev] [lld] contentHash in the Reader ?

[Nick Kledzik]

On May 7, 2013, at 10:38 PM, Michael Spencer <bigcheesegs at gmail.com> wrote:
> On Tue, May 7, 2013 at 10:08 PM, Nick Kledzik <kledzik at apple.com> wrote:
> Shankar,
> 
> Do you mean add a method like:
> 
>      virtual unsigned contentHash() const = 0;
> 
> or maybe:
> 
>      virtual llvm::hash_code contentHash() const = 0
> 
> to lld::DefinedAtom?  That seems good to me.   We just need to figure out what should happen with atoms not intended to be merged.  Should the method assert?  In the case where we want there to be a hash available, is it computed lazily?
> 
> Regarding the NativeReader/NativeWriter if the resolver is using the hash, then it would make sense to add the hash to the file format so reading native format is faster.
> 
> -Nick
> 
> I'd rather we use a crypto hash so we don't have to compare content at all.

The crypto hashes work well if the atom content is const data (e.g. c-string or other literals), since you just point the hash function at the range of bytes in the constant data.  Where it gets messier is if you are trying to coalesce non-leaf functions or non-const data because it is not just the content bytes that need to be compared but also all the references must somehow be incorporated into the hash. For example, two functions have the exact same instruction bytes, but one calls foo and one calls bar.

-Nick

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130508/371e22cc/attachment.html>