All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=727633

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg-sX2gwgM


Bot(s) for this bug's original alert(s):

linux

Caused by: "Reland of Enable LLD for POSIX LTO builds on Linux"
87e965ee819215cdcdd88eb26fb824194a04cd9a

Looks like lld increases binary size by 240kb on linux.

Taking a look.

I was able to reproduce the issue locally. lld's .text section was 240kb larger than gold's:

$ size -A chrome.gold | grep text
.text                      91696288    12097408
$ size -A chrome.lld | grep text
.text                  91926886    22441984

To help me investigate this issue, I wrote a program that takes two ELF binaries and tries to attribute the binaries' .text contents to symbol names, while trying to make the same attribution decisions for both binaries. (This is tricky in general when comparing binaries produced by two different linkers because the linkers may make different section ordering and ICF decisions.) The program sorts the attribution lists and prints them, so that I can diff them to see where the increase is coming from. Since I don't have anywhere else to put the program, I've attached it to the bug.

My program helped me identify a missed ICF opportunity, which Rui tracked down and fixed in LLVM r305134 (thanks Rui!). It looks like it did indeed fix part of the regression (when comparing the revisions before and after Rui's change the .text size of test_ime_driver.service decreased from 1577549 to 1577037 bytes, and the .text size of chrome decreased from 91988358 to 91930726 bytes), but I suspect that an unrelated change to LLVM since our last clang roll must have caused a binary size regression, because the chrome binary is still larger than before Rui's change.

In any event, it looks like we still have about 180kb to go on the linker side, and whatever we do will require a clang roll first, so I'm blocking this bug on the next clang roll.

Deleted: main.go 2.0 KB

main.go 2.0 KB View Download

Using my program I found another missed ICF opportunity and developed a fix: https://reviews.llvm.org/D34094

With that the chrome .text size decreases from 91930726 to 91637894 bytes.

My fix landed in LLVM r305177. Since the observed decrease in .text size was greater than the regression reported by this bug we should hopefully be able to declare this fixed once the clang roll happens.

Removing sheriff as owner has been found.

+agrieve@, estevenson@ for code in #4.

Neat! Didn't know go had an elf library at the ready.

I suspect your use-case could have been covered by //tools/binary_size/supersize, which is able to diff the symbols of two binaries, and understands ICF. However, it currently doesn't have support for parsing lld's linker map files ( bug 724599 ).

https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgtqX-rwoM

Looks like the size has recovered (and then some) as of the most recent clang roll, so I'm marking this bug as fixed.

Do you have the number of gold output size? LLD uses a different algorithm than gold for ICF, and our algorithm could theoretically achieve better results than gold. LLD can merge sections that have cyclic references while gold can't.

gold's .text size was 91696288 bytes in the revision of chromium that I was looking at.