025a5b22c8
Previously, we would add entries to DataInCodeSection in the order they appeared in input files. Because of this, entries would not be sorted if sections were reordered due to e.g. `-order_file` or call graph profile sorting. ld64 always keeps data-in-code information sorted. This commit also fixes an incorrect assertion. The original assertion from D103006 used to check that data-in-code entries are sorted in the input objects -- likely because we use binary search on that data. In D115556, the assertion was moved into `collectDataInCodeEntries`, but the checked variable's name was not changed, so it ended up checking the final contents of the DataInCodeSection. We no longer crash when building LLVM with PGO using an asserts build of LLD as the linker. Fixes https://bugs.chromium.org/p/chromium/issues/detail?id=1265937 Numbers for linking the Chromium Framework reproducer from #48001, which has 6829 data-in-code entries: x before + after N Min Max Median Avg Stddev x 20 2.1076453 2.3059683 2.1132485 2.1350302 0.049905767 + 20 2.1069031 2.3915262 2.14465 2.1728429 0.084065898 No difference proven at 95.0% confidence Differential Revision: https://reviews.llvm.org/D133581
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.