Hi Nick, 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
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
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
>
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>