- User Since
- Dec 30 2017, 7:39 PM (171 w, 3 d)
Apr 27 2018
The test results are interesting
You have to update
I think this is fine. I will run the benchmarks locally to confirm.
I really like the idea of changing the default, but maybe instead of an argument we should just have two functions:
Delete call to reserve.
correct patch .
Use end() when inserting. Doesn't make a difference in here, but is the canonical way of concatenating vectors.
Apr 26 2018
It is possible that xxhash is just too slow for use in a hash table. The experiment I did for pr37029 using hash_combine was still using strlen.
The part MC and Object part of this patch LGTM.
Since this is mainly about debug info and I not an expert in the area, please get one more LGTM before committing.
Implement the remaining suggestions.
Rebased and address some of the review comments.
Apr 25 2018
Apr 24 2018
Actually, I misread the location of the call to demoteSharedSymbols. I now think this is the proper fix as it just simplifies the symbols before we start processing the relocations.
I am finally trying to reduce what went wrong with this patch.
Since this is using information inside a single fragment when producing assembly I am OK with it.
Apr 23 2018
Apr 20 2018
Apr 19 2018
Have the OutputOffsets store just a uint64_t. This uses a bit of the hash for the live bit.
Apr 18 2018
Apr 16 2018
LGTM with a few last requests.
This is a plt by another name, no?
LGTM with the sort predicate fixed.
Apr 13 2018
No much difference for me:Function Name Total CPU(%) Total CPU (ms) * After the change: - lld.exe (PID: 15032) 100.00 4166 + lld::elf::MergeInputSection::splitIntoPieces 22.40 933 * Default (xxHash64): - lld.exe 100.00% 4254 + lld::elf::MergeInputSection::splitStrings 21.86% 930
Apr 12 2018
LGTM with a small change.
The results I got
My idea was actually to combine both patches.
I just noticed that hash_short will read at most 64 bytes of the string.
Interesting. The patch by itself seems fine. I will benchmark it locally.