Displaying 7 results from an estimated 7 matches for "nativewriter".
2013 May 07
2
[LLVMdev] [lld] contentHash in the Reader ?
...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
2013 May 08
0
[LLVMdev] [lld] contentHash in the Reader ?
...h_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 sp...
2013 May 08
4
[LLVMdev] [lld] contentHash in the Reader ?
...>
> 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:...
2013 Sep 23
2
[LLVMdev] [lld]Native reader/writer is not called, treated as Dead Code!
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
2013 Sep 23
0
[LLVMdev] [lld]Native reader/writer is not called, treated as Dead Code!
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::link() to side st...
2013 May 08
0
[LLVMdev] [lld] contentHash in the Reader ?
...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 a sha256/md5 o...
2013 May 08
0
[LLVMdev] [lld] contentHash in the Reader ?
...() 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 cons...