search for: nativeread

...ng 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

...ual 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...

...() 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...

Hi Nick, When changes were brought from lld core to the Universal Driver, calls to NativeReader/NativeWriter code was stripped away. Was this by accident ? Thanks Shankar Easwaran -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation

On Sep 23, 2013, at 10:02 AM, Shankar Easwaran <shankare at codeaurora.org> wrote: > Hi Nick, > > When changes were brought from lld core to the Universal Driver, calls to NativeReader/NativeWriter code was stripped away. This needs to be fixed. Originally, ever run of the linker would have a step were it wrote to native and read that back in. That makes sense for test cases, but not for a production linker. We could add a flag to LinkingContext which triggers Driver::li...

...y implemented in GOLD. In our C++ applications it is very effective in reducing the size of libraries in presence of templates and "machine-generated" code where functions differ essentially only by the type of some input pointer. <----snip---------> >> >> 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. Did you mean...

...gt;> >> To fix this, What is needed is >> >> a) A field in the NativeDefinedAtomIvarsV1 datastructure to hold the symbol size information that was present in the symbol table. >> b) A field in the DefinedAtom class to store the symbol size information (needed back for the NativeReader to construct the DefinedAtom object appropriately) >> >> Can I go ahead and do the modifications to the NativeDefinedAtomsIvarsV1 and the DefinedAtom class to store this additional attribute ? >> >> Thanks >> >> Shankar Easwaran >> >> -- >> Q...

...eded is >>> >>> a) A field in the NativeDefinedAtomIvarsV1 datastructure to hold the >>> symbol size information that was present in the symbol table. >>> b) A field in the DefinedAtom class to store the symbol size >>> information (needed back for the NativeReader to construct the >>> DefinedAtom object appropriately) >>> >>> Can I go ahead and do the modifications to the >>> NativeDefinedAtomsIvarsV1 and the DefinedAtom class to store this >>> additional attribute ? >>> >>> Thanks >>&...

...e 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...