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

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


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

win

There was additional assembly enabled in the high-bitdepth config that came in as part of this roll. 300K is a large jump, though so it will be good to find the source in libvpx's commit range.

This bisects to:

https://chromium.googlesource.com/webm/libvpx/+/0998a146d4f63c1758d1d1b941e7a33a1515695d
(Make vp9_scale_and_extend_frame_ssse3 work for hbd when bitdepth = 8.)

which is odd given the size of the module. The object for vp9_frame_scale_ssse3.c is ~7.5K. I haven't looked at the dumpbin output to see if there's anything obvious.

What seems to bring the issue out is the call to vp9_scale_and_extend_frame_c from the ssse3. The ssse3 intrinsics dep is brought into the same static_library(libvpx) as the c source (vp9_encoder.c), but there is a circular dependency. Making a copy of just vp9_scale_and_extend_frame_c in the ssse3 helps a bit, but the size still jumps over 100K possibly due to the deeper calls within it having the same issue.

The following revision refers to this bug:
  https://chromium.googlesource.com/webm/libvpx/+/2f31a1644587e53bc7b5381a009e611de94a65f0

commit 2f31a1644587e53bc7b5381a009e611de94a65f0
Author: James Zern <jzern@google.com>
Date: Thu Mar 09 05:13:50 2017

move vp9_scale_and_extend_frame_c to vp9_frame_scale.c

this is similar to the x86 configuration and helps mitigate an issue
with a circular dependency between this function and the ssse3 variant
causing an outsized increase in binary size (~300K for chrome)
chrome.dll:
.text 255B000 -> 252B000
.data 7B000 -> 75000
-221184 bytes

BUG= chromium:697956 

Change-Id: Ic95b142ecd62dd4f1795788aa27dd8fab59b708c

[modify] https://crrev.com/2f31a1644587e53bc7b5381a009e611de94a65f0/vp9/encoder/vp9_encoder.c
[modify] https://crrev.com/2f31a1644587e53bc7b5381a009e611de94a65f0/vp9/vp9cx.mk
[add] https://crrev.com/2f31a1644587e53bc7b5381a009e611de94a65f0/vp9/encoder/vp9_frame_scale.c

Is this fixed?

This roll brought in James' change:
https://chromium.googlesource.com/chromium/src/+/1b6af55955d20926d9b75d87fefb4ba15b540284

It dropped the graph by ~200k

#4 says the regression was ~300kb. Guess it's still being worked on?

~200k seems to be approximately what the comment in #7 expected. I don't believe it is still being worked on. The other 100k may have been in line with the new functions.

Great. Marked as fixed.

> I don't believe it is still being worked on. The other 100k may have been in line with the new functions.

There might be some additional artifacts like the one above, but this was the main contributor. I didn't look at the other functions in detail. We did make some minor table size and code adjustments later which should regain a few K, so let's see the result on chrome after this roll before going further.

https://chromeperf.appspot.com/report?sid=53763cec9d57d62cc09aa046b903097f78a6919cfdb67ce25a2e29546ba5ac69&start_rev=458825&end_rev=459158

looks like 195K regained. chrome.dll has grown some since we introduced the spike so it's still larger than at that time.

Is it worth bringing in brucedawson@ to ask if the Windows compiler is doing anything weird? I don't think this triggered on any of the other platforms.

Bruce has already talked about this behavior:
https://randomascii.wordpress.com/2017/01/22/delete-an-inline-function-save-794-kb/
https://randomascii.wordpress.com/2017/01/08/add-a-const-here-delete-a-const-there/