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

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


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

linux

I will take a look but I think this is a somewhat expected side effect of losing some minor size optimizations as a result of switching to ThinLTO.

There's probably not much we can do for now without a disproportionate amount of effort on the ThinLTO side. We already gained about 400kb (i.e. [1] minus [2]) with relatively straightforward  improvements to lld, which I think more than makes up for this regression.

[1] https://chromeperf.appspot.com/group_report?rev=475155
[2] https://chromeperf.appspot.com/group_report?rev=479214

Thanks! +benchmark owner, FYI.

Looks like the main culprit is .rodata, which is about 1.3mb larger with ThinLTO, which is balanced out by decreases in size of other sections, mostly .text (~800kb), .data.rel.ro (~160kb) and .rela.dyn (~180kb). Taking a closer look at the contents of .rodata I believe that I can attribute the increase to the missing optimization.

So it does seem like we could get a significant win out of re-implementing this optimization in ThinLTO. I will see if I can do that at some point, but it's not a huge priority for me right now.

 Issue 737389  has been merged into this issue.

Removing sheriff label since owner has been found.