[Ignition/turbo] Add a CallWithSpread bytecode.

[Ignition/turbo] Add a CallWithSpread bytecode.

Also, emit a NewWithSpread bytecode for CallNew AST nodes where possible, rather than desugaring in the parser.

BUG=v8:5511
Review-Url: https://codereview.chromium.org/2629363002
Cr-Original-Commit-Position: refs/heads/master@{#42455}
Committed: https://chromium.googlesource.com/v8/v8/+/4bae43471d5685e34d8bd74458889b83e60235a0
Review-Url: https://codereview.chromium.org/2629363002
Cr-Commit-Position: refs/heads/master@{#42590}
Committed: https://chromium.googlesource.com/v8/v8/+/96220730e688f01909ad61f437d1a8b88a58d173

[petermarshall, 2017-01-13 13:49:23]

The CQ bit was checked by petermarshall@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-01-13 13:49:33]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[petermarshall, 2017-01-13 13:50:41]

The CQ bit was checked by petermarshall@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-01-13 13:50:43]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-01-13 13:56:54]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-01-13 13:56:54]

Dry run: Try jobs failed on following builders:
  v8_win64_rel_ng on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_win64_rel_ng/builds/20733)
  v8_win_rel_ng on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_win_rel_ng/builds/20817)

[petermarshall, 2017-01-13 13:58:39]

petermarshall@chromium.org changed reviewers:
+ bmeurer@chromium.org, rmcilroy@chromium.org

[petermarshall, 2017-01-13 13:58:39]

PTAL. Basically the same as the first NewWithSpread CL with a few different
things. There is a bit of duplication, like in Runtime_CallWithSpread which is
very similar to Runtime_NewWithSpread, but my other CL
(https://codereview.chromium.org/2571563004) removes Runtime_NewWithSpread so
not much point combining them at this point.

[petermarshall, 2017-01-13 14:08:53]

The CQ bit was checked by petermarshall@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-01-13 14:09:02]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-01-13 14:34:13]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-01-13 14:34:14]

Dry run: Try jobs failed on following builders:
  v8_linux64_rel_ng on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_rel_ng/builds/19111)
  v8_linux64_rel_ng_triggered on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_rel_ng_triggered...)
  v8_win64_rel_ng on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_win64_rel_ng/builds/20737)
  v8_win64_rel_ng_triggered on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_win64_rel_ng_triggered/b...)

[Benedikt Meurer, 2017-01-14 18:37:15]

LGTM on compiler and runtime.

https://codereview.chromium.org/2629363002/diff/60001/src/interpreter/bytecod...
File src/interpreter/bytecode-generator.cc (right):

https://codereview.chromium.org/2629363002/diff/60001/src/interpreter/bytecod...
src/interpreter/bytecode-generator.cc:2533: DCHECK_EQ(expr->tail_call_mode(),
TailCallMode::kDisallow);
Nit: DCHECK_EQ(TailCallMode::kDisallow, ...)

[rmcilroy, 2017-01-16 10:29:40]

Looks like you've got some redness on the bots, but overall approach looks
reasonable. My only main issue is that this means that spread calls for
keyed/named properties will no longer have
ConvertReceiverMode::kNotNullOrUndefined in the BytecodeGraphBuilder (see
comment below).

https://codereview.chromium.org/2629363002/diff/60001/src/interpreter/bytecod...
File src/interpreter/bytecode-generator.cc (left):

https://codereview.chromium.org/2629363002/diff/60001/src/interpreter/bytecod...
src/interpreter/bytecode-generator.cc:2493: CHECK_EQ(expr->arguments()->length()
+ 1, args.register_count());
Please leave this DCHECK in for non spread calls (and it should work for spread
calls after you change the bytecode like NewWithSpread)

https://codereview.chromium.org/2629363002/diff/60001/src/interpreter/bytecod...
File src/interpreter/bytecode-generator.cc (right):

https://codereview.chromium.org/2629363002/diff/60001/src/interpreter/bytecod...
src/interpreter/bytecode-generator.cc:2424: if (!expr->arguments()->is_empty()
&& expr->arguments()->last()->IsSpread()) {
Could you pull this out to a boolean and reuse it here and below, or even
better, make it an attribute on the Call Expression?

https://codereview.chromium.org/2629363002/diff/60001/src/interpreter/bytecod...
src/interpreter/bytecode-generator.cc:2534: builder()->CallWithSpread(args);
The issue with this is that we already have a CallProperty call for named /
keyed property calls (decided via the call_type passed to builder()->Call(..)
below. Now we no longer get the information about whether a spread is a property
call or not. Personally I'm thinking we have far too many call bytecodes all of
which do mostly the same thing. Once CallWithSpread is more similar to the Call
bytecode (calling the InterpreterPushArgs, etc). Could we think about adding a
seperate argument to call which specifies the call type (e.g., property, spread,
tailcall, etc.) and only have a single handler for call. WDYT? Not necessary for
this CL, but please add a TODO if you think it's possible.

https://codereview.chromium.org/2629363002/diff/60001/src/interpreter/bytecod...
File src/interpreter/bytecodes.h (right):

https://codereview.chromium.org/2629363002/diff/60001/src/interpreter/bytecod...
src/interpreter/bytecodes.h:163: OperandType::kRegCount)                        
                           \
nit - move up below CallProperty

[petermarshall, 2017-01-16 11:59:38]

The CQ bit was checked by petermarshall@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-01-16 11:59:44]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-01-16 12:20:48]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-01-16 12:20:49]

Dry run: Try jobs failed on following builders:
  v8_win64_rel_ng on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_win64_rel_ng/builds/20830)
  v8_win64_rel_ng_triggered on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_win64_rel_ng_triggered/b...)

[petermarshall, 2017-01-16 13:16:29]

The CQ bit was checked by petermarshall@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-01-16 13:16:37]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[petermarshall, 2017-01-16 13:31:30]

The CQ bit was checked by petermarshall@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-01-16 13:31:36]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-01-16 14:11:44]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-01-16 14:11:46]

Dry run: This issue passed the CQ dry run.

[petermarshall, 2017-01-16 15:01:10]

Ross, PTAL =]

https://codereview.chromium.org/2629363002/diff/60001/src/interpreter/bytecod...
File src/interpreter/bytecode-generator.cc (left):

https://codereview.chromium.org/2629363002/diff/60001/src/interpreter/bytecod...
src/interpreter/bytecode-generator.cc:2493: CHECK_EQ(expr->arguments()->length()
+ 1, args.register_count());
On 2017/01/16 at 10:29:40, rmcilroy wrote:
> Please leave this DCHECK in for non spread calls (and it should work for
spread calls after you change the bytecode like NewWithSpread)

Yep, Done.

https://codereview.chromium.org/2629363002/diff/60001/src/interpreter/bytecod...
File src/interpreter/bytecode-generator.cc (right):

https://codereview.chromium.org/2629363002/diff/60001/src/interpreter/bytecod...
src/interpreter/bytecode-generator.cc:2424: if (!expr->arguments()->is_empty()
&& expr->arguments()->last()->IsSpread()) {
On 2017/01/16 at 10:29:40, rmcilroy wrote:
> Could you pull this out to a boolean and reuse it here and below, or even
better, make it an attribute on the Call Expression?

Yes I like it on the Call Expression (and CallNew), done.

https://codereview.chromium.org/2629363002/diff/60001/src/interpreter/bytecod...
src/interpreter/bytecode-generator.cc:2533: DCHECK_EQ(expr->tail_call_mode(),
TailCallMode::kDisallow);
On 2017/01/14 at 18:37:14, Benedikt Meurer wrote:
> Nit: DCHECK_EQ(TailCallMode::kDisallow, ...)

Done.

https://codereview.chromium.org/2629363002/diff/60001/src/interpreter/bytecod...
src/interpreter/bytecode-generator.cc:2534: builder()->CallWithSpread(args);
On 2017/01/16 at 10:29:40, rmcilroy wrote:
> The issue with this is that we already have a CallProperty call for named /
keyed property calls (decided via the call_type passed to builder()->Call(..)
below. Now we no longer get the information about whether a spread is a property
call or not. Personally I'm thinking we have far too many call bytecodes all of
which do mostly the same thing. Once CallWithSpread is more similar to the Call
bytecode (calling the InterpreterPushArgs, etc). Could we think about adding a
seperate argument to call which specifies the call type (e.g., property, spread,
tailcall, etc.) and only have a single handler for call. WDYT? Not necessary for
this CL, but please add a TODO if you think it's possible.

Yeah I think that suggestion makes sense - added a TODO higher up in this
function.

https://codereview.chromium.org/2629363002/diff/60001/src/interpreter/bytecod...
File src/interpreter/bytecodes.h (right):

https://codereview.chromium.org/2629363002/diff/60001/src/interpreter/bytecod...
src/interpreter/bytecodes.h:163: OperandType::kRegCount)                        
                           \
On 2017/01/16 at 10:29:40, rmcilroy wrote:
> nit - move up below CallProperty

Done.

[rmcilroy, 2017-01-16 16:04:35]

interpreter/ LGTM once comments are addressed.

https://codereview.chromium.org/2629363002/diff/90015/src/interpreter/bytecod...
File src/interpreter/bytecode-generator.cc (right):

https://codereview.chromium.org/2629363002/diff/90015/src/interpreter/bytecod...
src/interpreter/bytecode-generator.cc:2425: args =
register_allocator()->NewGrowableRegisterList();
nit - could you add a comment on why this is different for spread and a TODO to
remove this difference once the bytecode is changed.

https://codereview.chromium.org/2629363002/diff/90015/src/interpreter/bytecod...
src/interpreter/bytecode-generator.cc:2505: CHECK_EQ(expr->arguments()->length()
+ 1, args.register_count());
nit - please add a TODO to check this for spread calls when the bytecode
changes.

https://codereview.chromium.org/2629363002/diff/90015/src/interpreter/bytecod...
src/interpreter/bytecode-generator.cc:2541: builder()->CallWithSpread(args);
Please add a test to test-bytecode-generator which exercises this codepath.

https://codereview.chromium.org/2629363002/diff/90015/src/interpreter/bytecod...
src/interpreter/bytecode-generator.cc:2615: }
This seems like an unrelated change, could you do it in a separate CL please.

[petermarshall, 2017-01-17 08:38:19]

The CQ bit was checked by petermarshall@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-01-17 08:38:22]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[petermarshall, 2017-01-17 08:39:39]

Ross, PTAL at response to splitting CL

https://codereview.chromium.org/2629363002/diff/90015/src/interpreter/bytecod...
File src/interpreter/bytecode-generator.cc (right):

https://codereview.chromium.org/2629363002/diff/90015/src/interpreter/bytecod...
src/interpreter/bytecode-generator.cc:2425: args =
register_allocator()->NewGrowableRegisterList();
On 2017/01/16 at 16:04:35, rmcilroy wrote:
> nit - could you add a comment on why this is different for spread and a TODO
to remove this difference once the bytecode is changed.

Done

https://codereview.chromium.org/2629363002/diff/90015/src/interpreter/bytecod...
src/interpreter/bytecode-generator.cc:2505: CHECK_EQ(expr->arguments()->length()
+ 1, args.register_count());
On 2017/01/16 at 16:04:35, rmcilroy wrote:
> nit - please add a TODO to check this for spread calls when the bytecode
changes.

Done

https://codereview.chromium.org/2629363002/diff/90015/src/interpreter/bytecod...
src/interpreter/bytecode-generator.cc:2541: builder()->CallWithSpread(args);
On 2017/01/16 at 16:04:35, rmcilroy wrote:
> Please add a test to test-bytecode-generator which exercises this codepath.

Done

https://codereview.chromium.org/2629363002/diff/90015/src/interpreter/bytecod...
src/interpreter/bytecode-generator.cc:2615: }
On 2017/01/16 at 16:04:35, rmcilroy wrote:
> This seems like an unrelated change, could you do it in a separate CL please.

I thought about that but it is actually quite difficult to split them apart. In
parser-base.h we have to make sure we have the same number of
MaterializedLiterals as the parser. These new bytecodes mean that we don't
materialize any literals for the call/super call arguments as long as we can use
the bytecode, rather than the fallback desugaring in the parser.

Where we do that in the preparser, we don't have the info about whether this is
a super call, a regular call or a call to new, so having different behaviour for
these will break a test that expects the number of materialized literals to
always be the same between preparser and parser. Basically I think it would be
possible but might involve some refactoring or hackery that wouldn't really be
worth it. WDYT?

[commit-bot: I haz the power, 2017-01-17 09:06:43]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-01-17 09:06:44]

Dry run: This issue passed the CQ dry run.

[rmcilroy, 2017-01-17 10:11:31]

https://codereview.chromium.org/2629363002/diff/90015/src/interpreter/bytecod...
File src/interpreter/bytecode-generator.cc (right):

https://codereview.chromium.org/2629363002/diff/90015/src/interpreter/bytecod...
src/interpreter/bytecode-generator.cc:2615: }
On 2017/01/17 08:39:39, petermarshall wrote:
> On 2017/01/16 at 16:04:35, rmcilroy wrote:
> > This seems like an unrelated change, could you do it in a separate CL
please.
> 
> I thought about that but it is actually quite difficult to split them apart.
In
> parser-base.h we have to make sure we have the same number of
> MaterializedLiterals as the parser. These new bytecodes mean that we don't
> materialize any literals for the call/super call arguments as long as we can
use
> the bytecode, rather than the fallback desugaring in the parser.
> 
> Where we do that in the preparser, we don't have the info about whether this
is
> a super call, a regular call or a call to new, so having different behaviour
for
> these will break a test that expects the number of materialized literals to
> always be the same between preparser and parser. Basically I think it would be
> possible but might involve some refactoring or hackery that wouldn't really be
> worth it. WDYT?

I see, in that case I'm fine with it being here, but please update the CL
description to mention it makes this change too. Could you also add this case to
the test-bytecode-generator tests.

[petermarshall, 2017-01-17 10:58:27]

Description was changed from

==========
[Ignition/turbo] Add a CallWithSpread bytecode.

BUG=v8:5511
==========

to

==========
[Ignition/turbo] Add a CallWithSpread bytecode.

Also, emit a NewWithSpread bytecode for CallNew AST nodes where possible, rather
than desugaring in the parser.

BUG=v8:5511
==========

[petermarshall, 2017-01-18 08:28:06]

On 2017/01/17 at 10:11:31, rmcilroy wrote:

> I see, in that case I'm fine with it being here, but please update the CL
description to mention it makes this change too. Could you also add this case to
the test-bytecode-generator tests.

Done and done, thanks

[petermarshall, 2017-01-18 08:28:11]

The CQ bit was checked by petermarshall@chromium.org

[petermarshall, 2017-01-18 08:28:12]

The patchset sent to the CQ was uploaded after l-g-t-m from
bmeurer@chromium.org, rmcilroy@chromium.org
Link to the patchset: https://codereview.chromium.org/2629363002/#ps150001
(title: "Add a bytecode test for NewAndSpread")

[commit-bot: I haz the power, 2017-01-18 08:28:23]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-01-18 08:31:32]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-01-18 08:31:33]

Try jobs failed on following builders:
  v8_presubmit on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_presubmit/builds/32654)

[petermarshall, 2017-01-18 08:33:48]

petermarshall@chromium.org changed reviewers:
+ verwaest@chromium.org

[petermarshall, 2017-01-18 08:33:49]

Toon, could you PTAL for /parsing/* ?

[petermarshall, 2017-01-18 12:06:57]

The CQ bit was checked by petermarshall@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-01-18 12:07:09]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Toon Verwaest, 2017-01-18 12:09:54]

Can you add a test for spread+eval? That still doesn't seem to work right?

(function(){ var bla = 100; return eval(...["bla"]) })()

[commit-bot: I haz the power, 2017-01-18 12:37:04]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-01-18 12:37:05]

Dry run: This issue passed the CQ dry run.

[Toon Verwaest, 2017-01-18 12:43:12]

Other than that, the parser changes lgtm. We can also just consider this an
existing bug and land this CL as is ...

[petermarshall, 2017-01-18 12:54:30]

On 2017/01/18 at 12:43:12, verwaest wrote:
> Other than that, the parser changes lgtm. We can also just consider this an
existing bug and land this CL as is ...

Yeah that is still broken - there is a bug here:
https://bugs.chromium.org/p/v8/issues/detail?id=5690

I was going to look into that later, because it will be useful to have all the
machinery in bytecode-generator in place.

[petermarshall, 2017-01-18 12:57:14]

The CQ bit was checked by petermarshall@chromium.org

[petermarshall, 2017-01-18 12:57:14]

The patchset sent to the CQ was uploaded after l-g-t-m from
bmeurer@chromium.org, rmcilroy@chromium.org
Link to the patchset: https://codereview.chromium.org/2629363002/#ps170001
(title: "Remove unused builtin, rebase onto master after NewWithSpread landed")

[commit-bot: I haz the power, 2017-01-18 12:57:18]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-01-18 12:59:00]

CQ is committing da patch.

Bot data: {"patchset_id": 170001, "attempt_start_ts": 1484744234211850,
"parent_rev": "6c7d51c296c9a9e90e817b85d49100d08c03d94f", "commit_rev":
"4bae43471d5685e34d8bd74458889b83e60235a0"}

[commit-bot: I haz the power, 2017-01-18 12:59:06]

Description was changed from

==========
[Ignition/turbo] Add a CallWithSpread bytecode.

Also, emit a NewWithSpread bytecode for CallNew AST nodes where possible, rather
than desugaring in the parser.

BUG=v8:5511
==========

to

==========
[Ignition/turbo] Add a CallWithSpread bytecode.

Also, emit a NewWithSpread bytecode for CallNew AST nodes where possible, rather
than desugaring in the parser.

BUG=v8:5511

Review-Url: https://codereview.chromium.org/2629363002
Cr-Commit-Position: refs/heads/master@{#42455}
Committed:
https://chromium.googlesource.com/v8/v8/+/4bae43471d5685e34d8bd74458889b83e60...
==========

[commit-bot: I haz the power, 2017-01-18 12:59:07]

Committed patchset #10 (id:170001) as
https://chromium.googlesource.com/v8/v8/+/4bae43471d5685e34d8bd74458889b83e60...

[petermarshall, 2017-01-18 17:03:34]

A revert of this CL (patchset #10 id:170001) has been created in
https://codereview.chromium.org/2642843002/ by petermarshall@chromium.org.

The reason for reverting is: Causes a few bugs caught by clusterfuzz..

[petermarshall, 2017-01-19 13:25:10]

The CQ bit was checked by petermarshall@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-01-19 13:25:22]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[petermarshall, 2017-01-19 13:25:47]

The CQ bit was checked by petermarshall@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-01-19 13:25:52]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-01-19 13:27:22]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-01-19 13:27:23]

Dry run: Try jobs failed on following builders:
  v8_linux64_avx2_rel_ng on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_avx2_rel_ng/buil...)
  v8_linux64_rel_ng on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_rel_ng/builds/19528)
  v8_linux_gcc_compile_rel on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux_gcc_compile_rel/bu...)
  v8_linux_nodcheck_rel_ng on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux_nodcheck_rel_ng/bu...)
  v8_presubmit on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_presubmit/builds/32843)

[petermarshall, 2017-01-19 14:02:54]

The CQ bit was checked by petermarshall@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-01-19 14:02:57]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-01-19 14:39:55]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-01-19 14:39:56]

Dry run: This issue passed the CQ dry run.

[petermarshall, 2017-01-19 15:30:09]

The CQ bit was checked by petermarshall@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-01-19 15:30:14]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-01-19 15:32:03]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-01-19 15:32:05]

Dry run: This issue passed the CQ dry run.

[petermarshall, 2017-01-20 14:12:14]

Benedikt, could you PTAL before I re-land? Change is in parser.cc where we just
desugar instead of using new bytecodes.

[Benedikt Meurer, 2017-01-20 18:10:12]

LGTM, thanks.

[petermarshall, 2017-01-23 08:12:32]

The CQ bit was checked by petermarshall@chromium.org

[petermarshall, 2017-01-23 08:12:33]

The patchset sent to the CQ was uploaded after l-g-t-m from
rmcilroy@chromium.org, verwaest@chromium.org
Link to the patchset: https://codereview.chromium.org/2629363002/#ps230001
(title: "Disable bytecodes for tail calls")

[commit-bot: I haz the power, 2017-01-23 08:12:46]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[petermarshall, 2017-01-23 08:33:30]

The CQ bit was checked by petermarshall@chromium.org

[petermarshall, 2017-01-23 08:33:30]

The patchset sent to the CQ was uploaded after l-g-t-m from
bmeurer@chromium.org, rmcilroy@chromium.org, verwaest@chromium.org
Link to the patchset: https://codereview.chromium.org/2629363002/#ps250001
(title: "reparent on the bytecode CL")

[commit-bot: I haz the power, 2017-01-23 08:33:35]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-01-23 09:03:36]

CQ is committing da patch.

Bot data: {"patchset_id": 250001, "attempt_start_ts": 1485160410681090,
"parent_rev": "7b6ac70a4a07e7da74046ba2057488c8775c8931", "commit_rev":
"96220730e688f01909ad61f437d1a8b88a58d173"}

[commit-bot: I haz the power, 2017-01-23 09:03:41]

Description was changed from

==========
[Ignition/turbo] Add a CallWithSpread bytecode.

Also, emit a NewWithSpread bytecode for CallNew AST nodes where possible, rather
than desugaring in the parser.

BUG=v8:5511

Review-Url: https://codereview.chromium.org/2629363002
Cr-Commit-Position: refs/heads/master@{#42455}
Committed:
https://chromium.googlesource.com/v8/v8/+/4bae43471d5685e34d8bd74458889b83e60...
==========

to

==========
[Ignition/turbo] Add a CallWithSpread bytecode.

Also, emit a NewWithSpread bytecode for CallNew AST nodes where possible, rather
than desugaring in the parser.

BUG=v8:5511

Review-Url: https://codereview.chromium.org/2629363002
Cr-Original-Commit-Position: refs/heads/master@{#42455}
Committed:
https://chromium.googlesource.com/v8/v8/+/4bae43471d5685e34d8bd74458889b83e60...
Review-Url: https://codereview.chromium.org/2629363002
Cr-Commit-Position: refs/heads/master@{#42590}
Committed:
https://chromium.googlesource.com/v8/v8/+/96220730e688f01909ad61f437d1a8b88a5...
==========

[commit-bot: I haz the power, 2017-01-23 09:03:42]

Committed patchset #14 (id:250001) as
https://chromium.googlesource.com/v8/v8/+/96220730e688f01909ad61f437d1a8b88a5...