commit | 880a8de6ad2328d9151638d83e1754ca3e1e3a79 | [log] [tgz] |
---|---|---|
author | Reid Kleckner <rnk@google.com> | Mon Mar 22 14:56:44 2021 -0700 |
committer | Copybara-Service <copybara-worker@google.com> | Thu Mar 25 13:33:39 2021 -0700 |
tree | cb21e4a34766fbdfd8870937a09eed9dc5938ed3 | |
parent | fb5b54a3af1f0b9c1eb6fdbbce457ad81131a9e6 [diff] |
[COFF] Only consider associated EH sections during ICF The only known reason why ICF should not merge otherwise identical sections with differing associated sections has to do with exception handling tables. It's not clear what ICF should do when there are other kinds of associated sections. In every other case when this has come up, debug info and CF guard metadata, we have opted to make ICF ignore the associated sections. For comparison, ELF doesn't do anything for comdat groups. Instead, .eh_frame is parsed to figure out if a section has an LSDA, and if so, ICF is disabled. Another issue is that the order of associated sections is not defined. We have had issues in the past (crbug.com/1144476) where changing the order of the .xdata/.pdata sections in the object file lead to large ICF slowdowns. To address these issues, I decided it would be best to explicitly consider only .pdata and .xdata sections during ICF. This makes it easy to ignore the object file order, and I think it makes the intention of the code clearer. I've also made the children() accessor return an empty list for associated sections. This mostly only affects ICF and GC. This was the behavior before I made this a linked list, so the behavior change should be good. This had positive effects on chrome.dll: more .xdata sections were merged that previously could not be merged because they were associated with distinct .pdata sections. Reviewed By: mstorsjo Differential Revision: https://reviews.llvm.org/D98993 GitOrigin-RevId: 7ce9a3e9a91bb0c71cd3560079ff4c31d5dade1b
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.
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
.