X87: [runtime] Optimize and unify rest parameters.

X87: [runtime] Optimize and unify rest parameters.

  port 3ef573e9f127345cd9d04d7f9f5e51bf169ae103(r33809)

  original commit message:
  Replace the somewhat awkward RestParamAccessStub, which would always
  call into the runtime anyway with a proper FastNewRestParameterStub,
  which is basically based on the code that was already there for strict
  arguments object materialization. But for rest parameters we could
  optimize even further (leading to 8-10x improvements for functions with
  rest parameters), by fixing the internal formal parameter count:

  Every SharedFunctionInfo has a formal_parameter_count field, which
  specifies the number of formal parameters, and is used to decide whether
  we need to create an arguments adaptor frame when calling a function
  (i.e. if there's a mismatch between the actual and expected parameters).
  Previously the formal_parameter_count included the rest parameter, which
  was sort of unfortunate, as that meant that calling a function with only
  the non-rest parameters still required an arguments adaptor (plus some
  other oddities). Now with this CL we fix, so that we do no longer
  include the rest parameter in that count. Thereby checking for rest
  parameters is very efficient, as we only need to check whether there is
  an arguments adaptor frame, and if not create an empty array, otherwise
  check whether the arguments adaptor frame has more parameters than
  specified by the formal_parameter_count.

  The FastNewRestParameterStub is written in a way that it can be directly
  used by Ignition as well, and with some tweaks to the TurboFan backends
  and the CodeStubAssembler, we should be able to rewrite it as
  TurboFanCodeStub in the near future.

  Drive-by-fix: Refactor and unify the CreateArgumentsType which was
  different in TurboFan and Ignition; now we have a single enum class
  which is used in both TurboFan and Ignition.

BUG=

Committed: https://crrev.com/e59af013f74a41d973520e277646b90f442d709c
Cr-Commit-Position: refs/heads/master@{#33971}

[zhengxing.li, 2016-02-15 06:11:13]

zhengxing.li@intel.com changed reviewers:
+ bmeurer@chromium.org, chunyang.dai@intel.com, weiliang.lin@intel.com

[zhengxing.li, 2016-02-15 06:11:13]

PTAL, thanks!

[Weiliang, 2016-02-15 06:14:03]

lgtm

[zhengxing.li, 2016-02-15 06:16:47]

The CQ bit was checked by zhengxing.li@intel.com

[commit-bot: I haz the power, 2016-02-15 06:16:55]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1696063002/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1696063002/1

[commit-bot: I haz the power, 2016-02-15 06:40:32]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-02-15 06:41:02]

Description was changed from

==========
X87: [runtime] Optimize and unify rest parameters.

  port 3ef573e9f127345cd9d04d7f9f5e51bf169ae103(r33809)

  original commit message:
  Replace the somewhat awkward RestParamAccessStub, which would always
  call into the runtime anyway with a proper FastNewRestParameterStub,
  which is basically based on the code that was already there for strict
  arguments object materialization. But for rest parameters we could
  optimize even further (leading to 8-10x improvements for functions with
  rest parameters), by fixing the internal formal parameter count:

  Every SharedFunctionInfo has a formal_parameter_count field, which
  specifies the number of formal parameters, and is used to decide whether
  we need to create an arguments adaptor frame when calling a function
  (i.e. if there's a mismatch between the actual and expected parameters).
  Previously the formal_parameter_count included the rest parameter, which
  was sort of unfortunate, as that meant that calling a function with only
  the non-rest parameters still required an arguments adaptor (plus some
  other oddities). Now with this CL we fix, so that we do no longer
  include the rest parameter in that count. Thereby checking for rest
  parameters is very efficient, as we only need to check whether there is
  an arguments adaptor frame, and if not create an empty array, otherwise
  check whether the arguments adaptor frame has more parameters than
  specified by the formal_parameter_count.

  The FastNewRestParameterStub is written in a way that it can be directly
  used by Ignition as well, and with some tweaks to the TurboFan backends
  and the CodeStubAssembler, we should be able to rewrite it as
  TurboFanCodeStub in the near future.

  Drive-by-fix: Refactor and unify the CreateArgumentsType which was
  different in TurboFan and Ignition; now we have a single enum class
  which is used in both TurboFan and Ignition.

BUG=
==========

to

==========
X87: [runtime] Optimize and unify rest parameters.

  port 3ef573e9f127345cd9d04d7f9f5e51bf169ae103(r33809)

  original commit message:
  Replace the somewhat awkward RestParamAccessStub, which would always
  call into the runtime anyway with a proper FastNewRestParameterStub,
  which is basically based on the code that was already there for strict
  arguments object materialization. But for rest parameters we could
  optimize even further (leading to 8-10x improvements for functions with
  rest parameters), by fixing the internal formal parameter count:

  Every SharedFunctionInfo has a formal_parameter_count field, which
  specifies the number of formal parameters, and is used to decide whether
  we need to create an arguments adaptor frame when calling a function
  (i.e. if there's a mismatch between the actual and expected parameters).
  Previously the formal_parameter_count included the rest parameter, which
  was sort of unfortunate, as that meant that calling a function with only
  the non-rest parameters still required an arguments adaptor (plus some
  other oddities). Now with this CL we fix, so that we do no longer
  include the rest parameter in that count. Thereby checking for rest
  parameters is very efficient, as we only need to check whether there is
  an arguments adaptor frame, and if not create an empty array, otherwise
  check whether the arguments adaptor frame has more parameters than
  specified by the formal_parameter_count.

  The FastNewRestParameterStub is written in a way that it can be directly
  used by Ignition as well, and with some tweaks to the TurboFan backends
  and the CodeStubAssembler, we should be able to rewrite it as
  TurboFanCodeStub in the near future.

  Drive-by-fix: Refactor and unify the CreateArgumentsType which was
  different in TurboFan and Ignition; now we have a single enum class
  which is used in both TurboFan and Ignition.

BUG=

Committed: https://crrev.com/e59af013f74a41d973520e277646b90f442d709c
Cr-Commit-Position: refs/heads/master@{#33971}
==========

[commit-bot: I haz the power, 2016-02-15 06:41:03]

Patchset 1 (id:??) landed as
https://crrev.com/e59af013f74a41d973520e277646b90f442d709c
Cr-Commit-Position: refs/heads/master@{#33971}