LLD parses archive file index table only at first. When it finds a symbol
it is looking for is defined in a member file in an archive file, it actually
reads the member from the archive file. That's done in the core linker.
That's a single-thread process since the core linker is single threaded.
If your command line contains a few object files and a lot of archive files
(which is quite often the case), LLD hardly utilizes hardware parallelism.
This patch improves parallelism by speculatively instantiating archive
file members. At the beginning of the core linking, we first create a map
containing all symbols defined in all members, and each time we find a
new undefined symbol, we instantiate a member file containing the
symbol (if such a file exists). File instantiation is side effect free, so this
should not affect correctness.
This is a quick benchmark. Time to link self-link LLD executable:
Linux 9.78s -> 8.50s (0.86x)
Windows 6.18s -> 4.51s (0.73x)
If there is more than one archive having the same symbol name, the last file with the same symbol would be parsed. The archive library file which appears in link order should be the first one to get picked.
Weak symbols and common symbols have the same name across different archives. This doesnot appear to handle the case where the right weak symbol need to be chosen or the right common symbol be chosen.