llvm-project/lld
Fangrui Song 3d85424096 [ELF] Parse archives as --start-lib object files
https://maskray.me/blog/2022-01-16-archives-and-start-lib

For every definition in an extracted archive member, we intern the symbol twice,
once for the archive index entry, once for the .o symbol table after extraction.
This is inefficient.

Symbols in a --start-lib ObjFile/BitcodeFile are only interned once because the
result is cached in symbols[i].

Just handle an archive using the --start-lib code path. We can therefore remove
ArchiveFile and LazyArchive. For many projects, archive member extraction ratio
is high and it is a net performance win. Linking a Release build of clang is
1.01x as fast.

Note: --start-lib scans symbols in the same order that llvm-ar adds them to the
index, so in the common case the semantics should be identical. If the archive
symbol table was created in a different order, or is incomplete, this strategy
may have different semantics. Such cases are considered user error.

The `is neither ET_REL nor LLVM bitcode` error is changed to a warning.
Previously an archive may have such members without a diagnostic. Using a
warning prevents breakage.

* For some tests, the diagnostics get improved where we did not consider
  the archive member name: `b.a:` => `b.a(b.o):`.
* `no-obj.s`: the link is now allowed, matching GNU ld
* `archive-no-index.s`: the `is neither ET_REL nor LLVM bitcode` diagnostic is
  demoted to a warning.
* `incompatible.s`: even when an archive is unextracted, we may report an
  "incompatible with" error.

---

I recently decreased sizeof(SymbolUnion) by 8 and decreased memory usage quite a
bit, so retaining `symbols` for un-extracted archive members should not cause a
memory usage problem.

Reviewed By: peter.smith

Differential Revision: https://reviews.llvm.org/D119074
2022-02-15 09:38:00 -08:00
..
COFF Revert "try to fix windows build after 73e585e44d" and 2022-02-11 23:47:53 -08:00
Common [MLIR][GPU][lld] Use LLD bundled in ROCm, removing workaround 2022-02-10 19:37:30 +00:00
ELF [ELF] Parse archives as --start-lib object files 2022-02-15 09:38:00 -08:00
MachO [lld-macho] Unset ExportDynamic where possible for LTO 2022-02-11 22:26:19 -05:00
MinGW [LLD][MinGW] Add --heap argument support 2022-01-30 00:01:45 +02:00
cmake/modules [CMake] Factor out config prefix finding logic 2022-01-07 20:16:18 +00:00
docs [ELF][docs] Document "Output section type" 2022-02-14 09:52:20 -08:00
include/lld [MLIR][GPU][lld] Use LLD bundled in ROCm, removing workaround 2022-02-10 19:37:30 +00:00
test [ELF] Parse archives as --start-lib object files 2022-02-15 09:38:00 -08:00
tools/lld [LLD] Fix issue in HIP due to unspecified order of evaluation of the function object 2022-02-08 19:12:15 -05:00
utils
wasm [WebAssembly] Use GeneralDynamic TLS for exception handling builtins. 2022-02-14 14:08:32 -08:00
.clang-format
.clang-tidy NFC: .clang-tidy: Inherit configs from parents to improve maintainability 2021-06-08 08:25:59 -07:00
.gitignore
CMakeLists.txt [lld][clang][cmake] Clean up a few things 2022-02-03 20:01:28 +00:00
CODE_OWNERS.TXT Add code owners of new MachO port 2020-09-02 19:32:12 -07:00
LICENSE.TXT
README.md [doc] Place sha256 in lld/README.md into backticks 2021-01-12 10:19:40 -08:00

README.md

LLVM Linker (lld)

This directory and its subdirectories contain source code for the LLVM Linker, a modular cross platform linker which is built as part of the LLVM compiler infrastructure project.

lld is open source software. You may freely distribute it under the terms of the license agreement found in LICENSE.txt.

Benchmarking

In order to make sure various developers can evaluate patches over the same tests, we create a collection of self contained programs.

It is hosted at https://s3-us-west-2.amazonaws.com/linker-tests/lld-speed-test.tar.xz

The current sha256 is 10eec685463d5a8bbf08d77f4ca96282161d396c65bd97dc99dbde644a31610f.