[LLVMdev] [lld] contentHash in the Reader ?

Michael Spencer bigcheesegs at gmail.com
Tue May 7 22:38:46 PDT 2013


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.

- Michael Spencer


>
> On May 7, 2013, at 4:43 PM, Shankar Easwaran wrote:
> > Can we add a atomContentHash for DefinedAtoms when the atoms are being
> created. This can essentially speed up comparisons of atoms especially for
> >
> > * ICF (Identical code folding)
> > * Section groups (to identify similiar sections)
> >
> > Not sure where else this would help. This would essentially be used only
> by the Reader and the Resolver.
> >
> > There would be no change to the NativeReader/NativeWriter.
> >
> > 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/20130507/5d39291c/attachment.html>


More information about the llvm-dev mailing list