search for: contenthash

On 5/8/2013 12:38 AM, Michael Spencer 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 We could use a crypto hash too with the function prototype that looks like :- virtual lld::crypto::sha256 contentHash() const = 0 >> to lld::DefinedAtom? That seems good...

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

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

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

...rora.org>wrote: > On 5/8/2013 12:38 AM, Michael Spencer 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 >>> >> We could use a crypto hash too with the function prototype that looks > like :- > > virtual lld::crypto::sha256 contentHash() const =...

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

On Wed, May 8, 2013 at 6:03 PM, Rui Ueyama <ruiu at google.com> wrote: > I'd use SHA128 or MD5 as the linker does not handle hostile input. I think > as long as it's collision free, it should suffice. FWIW, the need for a collision free hash -- or *digest*, my preferred term -- is well known. Interestingly newer, supposedly "more secure" digest algorithms are also

On May 8, 2013, at 10:50 AM, Chandler Carruth <chandlerc at google.com> wrote: > > 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. If your primary criterion is through-put on large, desktop-class CPUs, Skein is likely

On Wed, May 8, 2013 at 9:13 PM, Owen Anderson <resistor at mac.com> wrote: > On May 8, 2013, at 10:50 AM, Chandler Carruth <chandlerc at google.com> > wrote: > > >> >>> 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),

On 5/8/2013 2:45 PM, Nick Kledzik wrote: > > 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

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

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

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