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

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


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

chromium-rel-win7-gpu-nvidia

Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8997021553571183952

=== Auto-CCing suspected CL author danno@chromium.org ===

Hi danno@chromium.org, the bisect results pointed to your CL below as possibly
causing a regression. Please have a look at this info and see whether
your CL be related.


===== BISECT JOB RESULTS =====
Status: completed


===== SUSPECTED CL(s) =====
Subject : [turbofan] Support variable size argument removal in TF-generated functions
Author  : danno
Commit description:
  
This is preparation for using TF to create builtins that handle variable number of
arguments and have to remove these arguments dynamically from the stack upon
return.

The gist of the changes:
- Added a second argument to the Return node which specifies the number of stack
  slots to pop upon return in addition to those specified by the Linkage of the
  compiled function.
- Removed Tail -> Non-Tail fallback in the instruction selector. Since TF now should
  handles all tail-call cases except where the return value type differs, this fallback
  was not really useful and in fact caused unexpected behavior with variable
  sized argument popping, since it wasn't possible to materialize a Return node
  with the right pop count from the TailCall without additional context.
- Modified existing Return generation to pass a constant zero as the additional
  pop argument since the variable pop functionality

LOG=N

Review-Url: https://codereview.chromium.org/2446543002
Cr-Commit-Position: refs/heads/master@{#40678}
Commit  : 5319b50c853c4213d825aa7cf620fde5d827f7eb
Date    : Mon Oct 31 16:54:24 2016


===== TESTED REVISIONS =====
Revision                       Mean     Std Dev  N   Good?
chromium@429239                3095.88  12.2837  8   good
chromium@429243                3091.0   11.373   5   good
chromium@429245                3110.64  35.6178  18  good
chromium@429246                3106.68  24.4412  62  good
chromium@429246,v8@fa33489ffd  3106.52  24.7131  62  good
chromium@429246,v8@fb96618ee0  3089.02  6.84951  5   good
chromium@429246,v8@5319b50c85  3123.28  27.7058  62  bad    <--
chromium@429246,v8@9c78194343  3115.27  17.1532  62  bad
chromium@429247                3128.87  19.3943  27  bad

Bisect job ran on: winx64nvidia_perf_bisect
Bug ID: 661936

Test Command: src/tools/perf/run_benchmark -v --browser=release_x64 --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests speedometer
Test Metric: Total/Total
Relative Change: 1.23%
Score: 99.9

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/winx64nvidia_perf_bisect/builds/1946
Job details: https://chromeperf.appspot.com/buildbucket_job_status/8997021553571183952


Not what you expected? We'll investigate and get back to you!
  https://chromeperf.appspot.com/bad_bisect?try_job_id=5581222028247040

| O O | Visit http://www.chromium.org/developers/speed-infra/perf-bug-faq
|  X  | for more information addressing perf regression bugs. For feedback,
| / \ | file a bug with component Tests>AutoBisect.  Thank you!

The graphs show a recovery shortly after this commit.