Do you know which CL regressed the binary size?

Yes, https://codereview.chromium.org/2762593002/ , in this commit https://chromium.googlesource.com/chromium/src/+/d238dae172d63175b562f99fc988e47e5213a244 (it was reverted in https://codereview.chromium.org/2837093003/)

The Android perf graph certainly noticed it:
https://chromeperf.appspot.com/report?sid=a097e74b1aa288511afb4cb616efe0f95ba4d347ad61d5e835072f23450938ba&num_points=1100

No bug was filed though, because the bot was running a few hours behind on Friday, and they go unmonitored on the weekend.

(no bug was filed because the issue was fixed by the time the graph was looked at again (Monday)

Isn't that something else? The regression this is about happened on April 24,  was in the tree for a day, and was for chrome_child.dll. As far as I know, no platform except Windows splits chrome along browser / renderer boundaries into two shared libraries.

Bah, Yes, you're right. Sorry for the noise. 

Here are the perf dashboard graphs around the regression: https://chromeperf.appspot.com/report?sid=bb67539906adc32fd1596f9e129277a24d964f554bc07902c7e40787f4ab269b&start_rev=465918&end_rev=467822

I am only seeing regressions of about 100k. Am I looking at the right thing? We only alert on regressions over 200k.

It regressed the size of chrome_child.dll (not chrome.dll) by 5MB. So that doesn't look like the right graph.

Ah, sorry about that. We were not monitoring chrome_child.dll. Added it to the config. +grt, sizes owner on Windows, as FYI