-
Notifications
You must be signed in to change notification settings - Fork 14.4k
[lld][ELF] Merge equivalent symbols found during ICF #139493
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
pranavk
wants to merge
8
commits into
llvm:main
Choose a base branch
from
pranavk:addends
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
Show all changes
8 commits
Select commit
Hold shift + click to select a range
faa11ed
Reapply "[lld] Merge equivalent symbols found during ICF (#134342)"
pranavk e4041b7
[lld][ICF] Don't merge symbols with different addends
pranavk adef51a
[lld] Disable section merging only for non-trivial relocations
pranavk 6b435f9
[lld][ELF] Prevent merging two sections when they point to non-globals
pranavk 6c41c38
Add tests for to prevent local-global merging
pranavk 3aaeac5
Address some of Fangrui's review comments
pranavk 0067993
Remove InputSection parameter from isTrivialRelocation after fake loc
pranavk 82a9d4b
clang-format
pranavk File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change was not in #134342 . I have tried to understand why the logic is so complex.
Looks like https://reviews.llvm.org/D34094 , while supporting MergeInputSection, also introduced the untested condition for InputSection
I feel that we should switch to the safer
da->value == db->value && addA == addB
, which likely doesn't lose anything (I believe it's difficult for clang emitted code to utilize the relaxed condition.)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think
da->value + addA == db->value + addB
is more readable. I can read it as if the address resolves to the same place, sections are considered same. It also takes care of section folding for more cases. Changing it toda->value == db->value && addA == addB
would exclude some cases.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The excluded cases are likely negligible. This condition is for InputSection (non merge string), where symbols defined not at offset 0 in -ffunction-sections -fdata-sections code are extremely rare. I don't know a case LLVM codegen would do this.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The chromium build that made us revert the original change did have many sections that were being merged due to this property and @zmodem tried my second commit in this PR (e4041b7) separately and noticed a binary size regression that was unacceptable to them. This comment on that Chromium bug is relevant: ~~
https://b.corp.google.com/issues/415810137#comment44(https://issues.chromium.org/issues/415810137#comment44)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you insist, I propose to do that in a separate PR so that these changes are not affected by any potential revert.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If it helps break disagreement, I lean towards @MaskRay 's suggestion to use
da->value == db->value && addA == addB
as the condition (same value, same addend). Maybe it misses something, but it's conceptually simpler even if it misses some case.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I corrected the link in my previous comment to a public one. Apologies I didn't notice that I pasted an internal link to the Chromium bug.
Using
da->value == db->value && addA == addB
may seem trivial but it misses cases that increases the size of chromium builds to unacceptable levels. As I mentioned in my previous comment, @zmodem had tried it already and noticed a large size regression.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I may be misremembering, but IIRC the only size impact we complained about was from the suggested workaround of using
--icf=safe
.I don't remember evaluating the size impact of this PR. We just tried it and confirmed it works (https://crbug.com/415810137#comment50), waited for it to get through review, and reverted the original change as the fix seemed to be taking a while.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm. Thanks for clarification. I was under the impression that after my comment here (https://issues.chromium.org/issues/415810137#comment50), you tried it and confirmed it works but the size regression was not acceptable to you.
I am okay simplifying the condition here after this clarification.