MIPS64: Fix '[runtime] Optimize and unify rest parameters.'.

MIPS64: Fix '[runtime] Optimize and unify rest parameters.'.

Port 3ef573e9f127345cd9d04d7f9f5e51bf169ae103

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.

TEST=test/mjsunit/harmony/destructuring, test/mjsunit/harmony/default-parameters,
test/mjsunit/harmony/default-parameters, test/mjsunit/es6/classes-subclass-builtins,
BUG=

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

[Alan Li, 2016-02-26 17:26:18]

Description was changed from

==========
MIPS64: Fix '[runtime] Optimize and unify rest parameters.'.

Port 3ef573e9f127345cd9d04d7f9f5e51bf169ae103

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.

TEST=test/mjsunit/harmony/destructuring,
test/mjsunit/harmony/default-parameters,
test/mjsunit/harmony/default-parameters,
test/mjsunit/es6/classes-subclass-builtins,
BUG=
==========

to

==========
MIPS64: Fix '[runtime] Optimize and unify rest parameters.'.

Port 3ef573e9f127345cd9d04d7f9f5e51bf169ae103

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.

TEST=test/mjsunit/harmony/destructuring,
test/mjsunit/harmony/default-parameters,
test/mjsunit/harmony/default-parameters,
test/mjsunit/es6/classes-subclass-builtins,
BUG=
==========

[Alan Li, 2016-02-26 17:26:18]

alan.li@imgtec.com changed reviewers:
+ akos.palfi@imgtec.com, balazs.kilvady@imgtec.com, gergely.kis@imgtec.com,
ilija.pavlovic.imgtec@gmail.com, ivica.bogosavljevic@imgtec.com

[balazs.kilvady, 2016-02-26 18:49:57]

LGTM. Nice catch.

[Alan Li, 2016-02-26 18:52:15]

The CQ bit was checked by alan.li@imgtec.com

[commit-bot: I haz the power, 2016-02-26 18:52:20]

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

[commit-bot: I haz the power, 2016-02-26 19:10:58]

Description was changed from

==========
MIPS64: Fix '[runtime] Optimize and unify rest parameters.'.

Port 3ef573e9f127345cd9d04d7f9f5e51bf169ae103

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.

TEST=test/mjsunit/harmony/destructuring,
test/mjsunit/harmony/default-parameters,
test/mjsunit/harmony/default-parameters,
test/mjsunit/es6/classes-subclass-builtins,
BUG=
==========

to

==========
MIPS64: Fix '[runtime] Optimize and unify rest parameters.'.

Port 3ef573e9f127345cd9d04d7f9f5e51bf169ae103

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.

TEST=test/mjsunit/harmony/destructuring,
test/mjsunit/harmony/default-parameters,
test/mjsunit/harmony/default-parameters,
test/mjsunit/es6/classes-subclass-builtins,
BUG=
==========

[commit-bot: I haz the power, 2016-02-26 19:10:59]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-02-26 19:12:57]

Description was changed from

==========
MIPS64: Fix '[runtime] Optimize and unify rest parameters.'.

Port 3ef573e9f127345cd9d04d7f9f5e51bf169ae103

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.

TEST=test/mjsunit/harmony/destructuring,
test/mjsunit/harmony/default-parameters,
test/mjsunit/harmony/default-parameters,
test/mjsunit/es6/classes-subclass-builtins,
BUG=
==========

to

==========
MIPS64: Fix '[runtime] Optimize and unify rest parameters.'.

Port 3ef573e9f127345cd9d04d7f9f5e51bf169ae103

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.

TEST=test/mjsunit/harmony/destructuring,
test/mjsunit/harmony/default-parameters,
test/mjsunit/harmony/default-parameters,
test/mjsunit/es6/classes-subclass-builtins,
BUG=

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

[commit-bot: I haz the power, 2016-02-26 19:12:58]

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