Save/restore only live registers in the generator suspend/resume.

This is a first step towards reducing the number of stores/loads when suspending/resuming a generator. 

Unfortunately, even for an empty generator, we still use 8 register for various things (try-finally, copies of generator object, parser-introduced temporaries). I will try to get rid of these in separate CLs.

Changes:

- SuspendGenerator bytecode now takes register list to save.
- ResumeGenerator was split into two bytecodes:
  * Resume generator reads the state out and marks the generator as
      'executing'.
  * RestoreGeneratorRegisters reloads the registers from 
      the generator.
    + this required adding support for output register list.

- Introduced generator_object_ register in the bytecode generator.
  * in subsequent CLs, I will make better use of it, the goal is
      to get rid if the .generator_object local variable.

- Taught register optimizer to flush unassigned registers.

BUG=v8:6379
Review-Url: https://codereview.chromium.org/2894293003
Cr-Commit-Position: refs/heads/master@{#45675}
Committed: https://chromium.googlesource.com/v8/v8/+/f0645612c42d170b449ae65205fdcbf2c48ae57b

[Jarin, 2017-05-20 19:44:06]

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

[commit-bot: I haz the power, 2017-05-20 19:44:13]

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-05-20 20:02:17]

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

[commit-bot: I haz the power, 2017-05-20 20:02:18]

Dry run: Try jobs failed on following builders:
  v8_linux64_gyp_rel_ng on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_gyp_rel_ng/build...)
  v8_linux64_gyp_rel_ng_triggered on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_gyp_rel_ng_trigg...)

[Jarin, 2017-05-29 11:45:30]

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

[commit-bot: I haz the power, 2017-05-29 11:45:39]

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-05-29 12:00:08]

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

[commit-bot: I haz the power, 2017-05-29 12:00:09]

Dry run: Try jobs failed on following builders:
  v8_linux64_gyp_rel_ng on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_gyp_rel_ng/build...)
  v8_linux64_gyp_rel_ng_triggered on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_gyp_rel_ng_trigg...)

[Jarin, 2017-05-29 12:51:43]

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

[commit-bot: I haz the power, 2017-05-29 12:51:49]

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-05-29 13:27:50]

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

[commit-bot: I haz the power, 2017-05-29 13:27:50]

Dry run: This issue passed the CQ dry run.

[Jarin, 2017-06-01 08:31:20]

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

[commit-bot: I haz the power, 2017-06-01 08:31:25]

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-06-01 08:36:14]

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

[commit-bot: I haz the power, 2017-06-01 08:36:16]

Dry run: Try jobs failed on following builders:
  v8_linux64_verify_csa_rel_ng on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_verify_csa_rel_n...)

[Jarin, 2017-06-01 09:25:44]

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

[commit-bot: I haz the power, 2017-06-01 09:25:55]

Dry run: CQ is trying da patch.

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

[Jarin, 2017-06-01 09:37:49]

Description was changed from

==========
Move generator resumption after the switch.
==========

to

==========
This is a first step towards reducing the number of stores/loads when
suspending/resuming a generator. 

Unfortunately, even for an empty generator, we still use 8 register for various
things (try-finally, copies of generator object, parser-introduced temporaries).
I will try to get rid of these in separate CLs.

Changes:

- SuspendGenerator bytecode now takes register list to save.
- ResumeGenerator was split into two bytecodes:
  * Resume generator reads the state out and marks the generator as
      'executing'.
  * RestoreGeneratorRegisters reloads the registers from 
      the generator.
    + this required adding support for output register list.

- Introduced generator_object_ register in the bytecode generator.
  * in subsequent CLs, I will make better use of it, the goal is
      to get rid if the .generator_object local variable.

- Taught register optimizer to flush unassigned registers.
==========

[Jarin, 2017-06-01 09:37:49]

jarin@chromium.org changed reviewers:
+ neis@chromium.org, rmcilroy@chromium.org

[Jarin, 2017-06-01 09:38:37]

Could you take a look, please?

[Jarin, 2017-06-01 09:40:23]

Description was changed from

==========
This is a first step towards reducing the number of stores/loads when
suspending/resuming a generator. 

Unfortunately, even for an empty generator, we still use 8 register for various
things (try-finally, copies of generator object, parser-introduced temporaries).
I will try to get rid of these in separate CLs.

Changes:

- SuspendGenerator bytecode now takes register list to save.
- ResumeGenerator was split into two bytecodes:
  * Resume generator reads the state out and marks the generator as
      'executing'.
  * RestoreGeneratorRegisters reloads the registers from 
      the generator.
    + this required adding support for output register list.

- Introduced generator_object_ register in the bytecode generator.
  * in subsequent CLs, I will make better use of it, the goal is
      to get rid if the .generator_object local variable.

- Taught register optimizer to flush unassigned registers.
==========

to

==========
This is a first step towards reducing the number of stores/loads when
suspending/resuming a generator. 

Unfortunately, even for an empty generator, we still use 8 register for various
things (try-finally, copies of generator object, parser-introduced temporaries).
I will try to get rid of these in separate CLs.

Changes:

- SuspendGenerator bytecode now takes register list to save.
- ResumeGenerator was split into two bytecodes:
  * Resume generator reads the state out and marks the generator as
      'executing'.
  * RestoreGeneratorRegisters reloads the registers from 
      the generator.
    + this required adding support for output register list.

- Introduced generator_object_ register in the bytecode generator.
  * in subsequent CLs, I will make better use of it, the goal is
      to get rid if the .generator_object local variable.

- Taught register optimizer to flush unassigned registers.

BUG=v8:6379
==========

[rmcilroy, 2017-06-01 10:44:44]

Overall looks good. A couple of comments and suggestions.

https://codereview.chromium.org/2894293003/diff/160001/src/interpreter/byteco...
File src/interpreter/bytecode-generator.cc (right):

https://codereview.chromium.org/2894293003/diff/160001/src/interpreter/byteco...
src/interpreter/bytecode-generator.cc:988: .ResumeGenerator(generator_object_)
How about we merge GeneratorGetContext into the ResumeGenerator bytecode and do
them both at the same time? (Possibly a followup CL)

https://codereview.chromium.org/2894293003/diff/160001/src/interpreter/byteco...
src/interpreter/bytecode-generator.cc:2534: .SuspendGenerator(generator,
registers_to_save, expr->flags());
Let's rename this SaveGeneratorRegisters now to match up with
RestoreGeneratorRegisters.

https://codereview.chromium.org/2894293003/diff/160001/src/interpreter/byteco...
src/interpreter/bytecode-generator.cc:2562:
.StoreAccumulatorInRegister(generator_object_);
Any reason to pass generator_object_ back in accumulator and reset the register
here - won't it be part of the restored registers?

https://codereview.chromium.org/2894293003/diff/160001/src/interpreter/byteco...
File src/interpreter/bytecode-register-optimizer.cc (right):

https://codereview.chromium.org/2894293003/diff/160001/src/interpreter/byteco...
src/interpreter/bytecode-register-optimizer.cc:250:
reg_info->MoveToNewEquivalenceSet(NextEquivalenceId(), true);
Why do these need moved here? If it's because they don't count as materialized,
could we instead initialize registers as being materialized in the constructor /
GrowRegisterMap? (Flush is already expensive, so I'd rather not do more work
here if possible)

https://codereview.chromium.org/2894293003/diff/160001/src/interpreter/byteco...
File src/interpreter/bytecode-register-optimizer.h (right):

https://codereview.chromium.org/2894293003/diff/160001/src/interpreter/byteco...
src/interpreter/bytecode-register-optimizer.h:70: bytecode ==
Bytecode::kResumeGenerator ||
Remove ResumeGenerator from here now.

https://codereview.chromium.org/2894293003/diff/160001/src/interpreter/byteco...
src/interpreter/bytecode-register-optimizer.h:79: // - a generator resume (as
this involves restoring all registers).
update comment please

https://codereview.chromium.org/2894293003/diff/160001/src/interpreter/byteco...
File src/interpreter/bytecodes.h (right):

https://codereview.chromium.org/2894293003/diff/160001/src/interpreter/byteco...
src/interpreter/bytecodes.h:320: V(ResumeGenerator, AccumulatorUse::kWrite,
OperandType::kReg)                \
nit - move ResumeGenerator first

https://codereview.chromium.org/2894293003/diff/160001/src/interpreter/interp...
File src/interpreter/interpreter-generator.cc (right):

https://codereview.chromium.org/2894293003/diff/160001/src/interpreter/interp...
src/interpreter/interpreter-generator.cc:3615: // SuspendGenerator <generator>
<input-register-list> <flags>
nit - <input-register-list> -> <first input register> <register count>

https://codereview.chromium.org/2894293003/diff/160001/src/interpreter/interp...
src/interpreter/interpreter-generator.cc:3641: // Bytecode operand 2 is the
number of registers to store to the generator.
You don't ever check operand 1 - could you add a CSA assert that it is the
expected register 0.

https://codereview.chromium.org/2894293003/diff/160001/src/interpreter/interp...
src/interpreter/interpreter-generator.cc:3710: // RestoreGeneratorRegisters
<generator> <output-register-list>
nit - <output-register-list> -> <first output register> <register count>

https://codereview.chromium.org/2894293003/diff/160001/src/interpreter/interp...
src/interpreter/interpreter-generator.cc:3716: // ignore it.
Please add a CSA assert

[Jarin, 2017-06-01 12:46:50]

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

[commit-bot: I haz the power, 2017-06-01 12:46:56]

Dry run: CQ is trying da patch.

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

[Jarin, 2017-06-01 12:48:22]

https://codereview.chromium.org/2894293003/diff/160001/src/interpreter/byteco...
File src/interpreter/bytecode-generator.cc (right):

https://codereview.chromium.org/2894293003/diff/160001/src/interpreter/byteco...
src/interpreter/bytecode-generator.cc:988: .ResumeGenerator(generator_object_)
On 2017/06/01 10:44:44, rmcilroy wrote:
> How about we merge GeneratorGetContext into the ResumeGenerator bytecode and
do
> them both at the same time? (Possibly a followup CL)

They both need to return value. Is it common to use multi-value return?

https://codereview.chromium.org/2894293003/diff/160001/src/interpreter/byteco...
src/interpreter/bytecode-generator.cc:2534: .SuspendGenerator(generator,
registers_to_save, expr->flags());
On 2017/06/01 10:44:44, rmcilroy wrote:
> Let's rename this SaveGeneratorRegisters now to match up with
> RestoreGeneratorRegisters.

It actually does more work than just saving register, so perhaps we should not
rename.

https://codereview.chromium.org/2894293003/diff/160001/src/interpreter/byteco...
src/interpreter/bytecode-generator.cc:2562:
.StoreAccumulatorInRegister(generator_object_);
On 2017/06/01 10:44:44, rmcilroy wrote:
> Any reason to pass generator_object_ back in accumulator and reset the
register
> here - won't it be part of the restored registers?

Done.

https://codereview.chromium.org/2894293003/diff/160001/src/interpreter/byteco...
File src/interpreter/bytecode-register-optimizer.cc (right):

https://codereview.chromium.org/2894293003/diff/160001/src/interpreter/byteco...
src/interpreter/bytecode-register-optimizer.cc:250:
reg_info->MoveToNewEquivalenceSet(NextEquivalenceId(), true);
On 2017/06/01 10:44:44, rmcilroy wrote:
> Why do these need moved here? If it's because they don't count as
materialized,
> could we instead initialize registers as being materialized in the constructor
/
> GrowRegisterMap? (Flush is already expensive, so I'd rather not do more work
> here if possible)

Yes, it's because they do not count as materialized. I had added this code
because it seemed to be the safest option. 

Now it is removed and the materialization is set in GrowRegisterMap.

Thanks for the suggestion!

https://codereview.chromium.org/2894293003/diff/160001/src/interpreter/byteco...
File src/interpreter/bytecode-register-optimizer.h (right):

https://codereview.chromium.org/2894293003/diff/160001/src/interpreter/byteco...
src/interpreter/bytecode-register-optimizer.h:70: bytecode ==
Bytecode::kResumeGenerator ||
On 2017/06/01 10:44:44, rmcilroy wrote:
> Remove ResumeGenerator from here now.

Done.

https://codereview.chromium.org/2894293003/diff/160001/src/interpreter/byteco...
src/interpreter/bytecode-register-optimizer.h:79: // - a generator resume (as
this involves restoring all registers).
On 2017/06/01 10:44:44, rmcilroy wrote:
> update comment please

Done.

https://codereview.chromium.org/2894293003/diff/160001/src/interpreter/byteco...
File src/interpreter/bytecodes.h (right):

https://codereview.chromium.org/2894293003/diff/160001/src/interpreter/byteco...
src/interpreter/bytecodes.h:320: V(ResumeGenerator, AccumulatorUse::kWrite,
OperandType::kReg)                \
On 2017/06/01 10:44:44, rmcilroy wrote:
> nit - move ResumeGenerator first

Done.

https://codereview.chromium.org/2894293003/diff/160001/src/interpreter/interp...
File src/interpreter/interpreter-generator.cc (right):

https://codereview.chromium.org/2894293003/diff/160001/src/interpreter/interp...
src/interpreter/interpreter-generator.cc:3615: // SuspendGenerator <generator>
<input-register-list> <flags>
On 2017/06/01 10:44:44, rmcilroy wrote:
> nit - <input-register-list> -> <first input register> <register count>

Done.

https://codereview.chromium.org/2894293003/diff/160001/src/interpreter/interp...
src/interpreter/interpreter-generator.cc:3641: // Bytecode operand 2 is the
number of registers to store to the generator.
On 2017/06/01 10:44:44, rmcilroy wrote:
> You don't ever check operand 1 - could you add a CSA assert that it is the
> expected register 0.

Done.

https://codereview.chromium.org/2894293003/diff/160001/src/interpreter/interp...
src/interpreter/interpreter-generator.cc:3710: // RestoreGeneratorRegisters
<generator> <output-register-list>
On 2017/06/01 10:44:44, rmcilroy wrote:
> nit - <output-register-list> -> <first output register> <register count>

Done.

https://codereview.chromium.org/2894293003/diff/160001/src/interpreter/interp...
src/interpreter/interpreter-generator.cc:3716: // ignore it.
On 2017/06/01 10:44:44, rmcilroy wrote:
> Please add a CSA assert

Done.

[commit-bot: I haz the power, 2017-06-01 13:18:55]

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

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

Dry run: This issue passed the CQ dry run.

[rmcilroy, 2017-06-01 13:20:23]

https://codereview.chromium.org/2894293003/diff/160001/src/interpreter/byteco...
File src/interpreter/bytecode-generator.cc (right):

https://codereview.chromium.org/2894293003/diff/160001/src/interpreter/byteco...
src/interpreter/bytecode-generator.cc:988: .ResumeGenerator(generator_object_)
On 2017/06/01 12:48:22, Jarin wrote:
> On 2017/06/01 10:44:44, rmcilroy wrote:
> > How about we merge GeneratorGetContext into the ResumeGenerator bytecode and
> do
> > them both at the same time? (Possibly a followup CL)
> 
> They both need to return value. Is it common to use multi-value return?

It's not common, but it's possible (e.g, use a RegOutPair and allocate both
registers such that they are a RegList pair)

https://codereview.chromium.org/2894293003/diff/160001/src/interpreter/byteco...
src/interpreter/bytecode-generator.cc:2534: .SuspendGenerator(generator,
registers_to_save, expr->flags());
On 2017/06/01 12:48:22, Jarin wrote:
> On 2017/06/01 10:44:44, rmcilroy wrote:
> > Let's rename this SaveGeneratorRegisters now to match up with
> > RestoreGeneratorRegisters.
> 
> It actually does more work than just saving register, so perhaps we should not
> rename.

It's quite different from RestoreGenerator now though, so I'd prefer not to be
symmetric with that bytecode name.

[neis, 2017-06-01 13:34:37]

https://codereview.chromium.org/2894293003/diff/180001/src/interpreter/interp...
File src/interpreter/interpreter-generator.cc (right):

https://codereview.chromium.org/2894293003/diff/180001/src/interpreter/interp...
src/interpreter/interpreter-generator.cc:3697: //
Maybe we can rename this to RestoreGeneratorState.

https://codereview.chromium.org/2894293003/diff/180001/src/interpreter/interp...
src/interpreter/interpreter-generator.cc:3733: 
You're still writing the generator into the accumulator here.

[neis, 2017-06-01 13:36:35]

Other than that, lgtm!

[rmcilroy, 2017-06-01 14:04:20]

https://codereview.chromium.org/2894293003/diff/180001/src/interpreter/interp...
File src/interpreter/interpreter-generator.cc (right):

https://codereview.chromium.org/2894293003/diff/180001/src/interpreter/interp...
src/interpreter/interpreter-generator.cc:3697: //
On 2017/06/01 13:34:37, neis wrote:
> Maybe we can rename this to RestoreGeneratorState.

SGTM

[rmcilroy, 2017-06-01 14:05:00]

https://codereview.chromium.org/2894293003/diff/180001/src/interpreter/interp...
File src/interpreter/interpreter-generator.cc (right):

https://codereview.chromium.org/2894293003/diff/180001/src/interpreter/interp...
src/interpreter/interpreter-generator.cc:3733: 
On 2017/06/01 13:34:37, neis wrote:
> You're still writing the generator into the accumulator here.

Also update AcumulatorUse to kNone in bytecodes.h

[adamk, 2017-06-01 17:36:18]

Re: reducing register use, I have a WIP CL to slim down register use in
BytecodeGenerator::ResumeGenerator, lmk if that'd be useful.

[Jarin, 2017-06-02 09:32:39]

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

[commit-bot: I haz the power, 2017-06-02 09:32:47]

Dry run: CQ is trying da patch.

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

[Jarin, 2017-06-02 09:35:50]

Could you take another look, please?

https://codereview.chromium.org/2894293003/diff/180001/src/interpreter/interp...
File src/interpreter/interpreter-generator.cc (right):

https://codereview.chromium.org/2894293003/diff/180001/src/interpreter/interp...
src/interpreter/interpreter-generator.cc:3697: //
On 2017/06/01 14:04:20, rmcilroy wrote:
> On 2017/06/01 13:34:37, neis wrote:
> > Maybe we can rename this to RestoreGeneratorState.
> 
> SGTM

Done.

We could also get completely rid of the bytecode and just expand this to the
load of the state into generator_state_ and then store of the kExecuting state
into the generator (in BuildGeneratorPrologue). WDYT? (But not in this CL.)

https://codereview.chromium.org/2894293003/diff/180001/src/interpreter/interp...
src/interpreter/interpreter-generator.cc:3733: 
On 2017/06/01 14:05:00, rmcilroy wrote:
> On 2017/06/01 13:34:37, neis wrote:
> > You're still writing the generator into the accumulator here.
> 
> Also update AcumulatorUse to kNone in bytecodes.h

Done.

https://codereview.chromium.org/2894293003/diff/180001/src/interpreter/interp...
src/interpreter/interpreter-generator.cc:3733: 
On 2017/06/01 13:34:37, neis wrote:
> You're still writing the generator into the accumulator here.

Done.

[rmcilroy, 2017-06-02 09:42:06]

https://codereview.chromium.org/2894293003/diff/180001/src/interpreter/interp...
File src/interpreter/interpreter-generator.cc (right):

https://codereview.chromium.org/2894293003/diff/180001/src/interpreter/interp...
src/interpreter/interpreter-generator.cc:3697: //
On 2017/06/02 09:35:49, Jarin wrote:
> On 2017/06/01 14:04:20, rmcilroy wrote:
> > On 2017/06/01 13:34:37, neis wrote:
> > > Maybe we can rename this to RestoreGeneratorState.
> > 
> > SGTM
> 
> Done.
> 
> We could also get completely rid of the bytecode and just expand this to the
> load of the state into generator_state_ and then store of the kExecuting state
> into the generator (in BuildGeneratorPrologue). WDYT? (But not in this CL.)

I'm not quite sure what you mean here - do you mean emit bytecode to do the heap
object field loads directly? We don't currently have any bytecodes for getting a
field off of a heap object (although given that  3 generator intrinsics do
exactly that, I think we should think about adding one).

[Jarin, 2017-06-02 09:45:55]

On 2017/06/02 09:42:06, rmcilroy wrote:
>
https://codereview.chromium.org/2894293003/diff/180001/src/interpreter/interp...
> File src/interpreter/interpreter-generator.cc (right):
> 
>
https://codereview.chromium.org/2894293003/diff/180001/src/interpreter/interp...
> src/interpreter/interpreter-generator.cc:3697: //
> On 2017/06/02 09:35:49, Jarin wrote:
> > On 2017/06/01 14:04:20, rmcilroy wrote:
> > > On 2017/06/01 13:34:37, neis wrote:
> > > > Maybe we can rename this to RestoreGeneratorState.
> > > 
> > > SGTM
> > 
> > Done.
> > 
> > We could also get completely rid of the bytecode and just expand this to the
> > load of the state into generator_state_ and then store of the kExecuting
state
> > into the generator (in BuildGeneratorPrologue). WDYT? (But not in this CL.)
> 
> I'm not quite sure what you mean here - do you mean emit bytecode to do the
heap
> object field loads directly? We don't currently have any bytecodes for getting
a
> field off of a heap object (although given that  3 generator intrinsics do
> exactly that, I think we should think about adding one).

Yeah, that's what I meant (not realizing that we do not have machinery for
doing arbitrary LoadField/StoreField).

[rmcilroy, 2017-06-02 10:00:29]

LGTM, thanks.

[commit-bot: I haz the power, 2017-06-02 10:02:47]

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

[commit-bot: I haz the power, 2017-06-02 10:02:48]

Dry run: This issue passed the CQ dry run.

[neis, 2017-06-02 10:04:40]

https://codereview.chromium.org/2894293003/diff/200001/src/isolate.cc
File src/isolate.cc (right):

https://codereview.chromium.org/2894293003/diff/200001/src/isolate.cc#newcode...
src/isolate.cc:1321:
CHECK(js_frame->ReadInterpreterRegister(context_reg)->IsContext());
Maybe remove this again, I guess it's a debugging leftover.

[neis, 2017-06-02 10:05:28]

On 2017/06/02 09:42:06, rmcilroy wrote:

> I'm not quite sure what you mean here - do you mean emit bytecode to do the
heap
> object field loads directly? We don't currently have any bytecodes for getting
a
> field off of a heap object (although given that  3 generator intrinsics do
> exactly that, I think we should think about adding one).

Agreed.

[Jarin, 2017-06-02 10:24:41]

The CQ bit was checked by jarin@chromium.org

[Jarin, 2017-06-02 10:24:42]

The patchset sent to the CQ was uploaded after l-g-t-m from neis@chromium.org,
rmcilroy@chromium.org
Link to the patchset: https://codereview.chromium.org/2894293003/#ps220001
(title: "Tweak")

[commit-bot: I haz the power, 2017-06-02 10:24:48]

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-06-02 11:55:49]

CQ is committing da patch.

Bot data: {"patchset_id": 220001, "attempt_start_ts": 1496399081763290,
"parent_rev": "19f7cc497abf309fe52017d7363798aa0a74f0f8", "commit_rev":
"f0645612c42d170b449ae65205fdcbf2c48ae57b"}

[commit-bot: I haz the power, 2017-06-02 11:55:54]

Description was changed from

==========
This is a first step towards reducing the number of stores/loads when
suspending/resuming a generator. 

Unfortunately, even for an empty generator, we still use 8 register for various
things (try-finally, copies of generator object, parser-introduced temporaries).
I will try to get rid of these in separate CLs.

Changes:

- SuspendGenerator bytecode now takes register list to save.
- ResumeGenerator was split into two bytecodes:
  * Resume generator reads the state out and marks the generator as
      'executing'.
  * RestoreGeneratorRegisters reloads the registers from 
      the generator.
    + this required adding support for output register list.

- Introduced generator_object_ register in the bytecode generator.
  * in subsequent CLs, I will make better use of it, the goal is
      to get rid if the .generator_object local variable.

- Taught register optimizer to flush unassigned registers.

BUG=v8:6379
==========

to

==========
This is a first step towards reducing the number of stores/loads when
suspending/resuming a generator. 

Unfortunately, even for an empty generator, we still use 8 register for various
things (try-finally, copies of generator object, parser-introduced temporaries).
I will try to get rid of these in separate CLs.

Changes:

- SuspendGenerator bytecode now takes register list to save.
- ResumeGenerator was split into two bytecodes:
  * Resume generator reads the state out and marks the generator as
      'executing'.
  * RestoreGeneratorRegisters reloads the registers from 
      the generator.
    + this required adding support for output register list.

- Introduced generator_object_ register in the bytecode generator.
  * in subsequent CLs, I will make better use of it, the goal is
      to get rid if the .generator_object local variable.

- Taught register optimizer to flush unassigned registers.

BUG=v8:6379

Review-Url: https://codereview.chromium.org/2894293003
Cr-Commit-Position: refs/heads/master@{#45675}
Committed:
https://chromium.googlesource.com/v8/v8/+/f0645612c42d170b449ae65205fdcbf2c48...
==========

[commit-bot: I haz the power, 2017-06-02 11:55:55]

Committed patchset #12 (id:220001) as
https://chromium.googlesource.com/v8/v8/+/f0645612c42d170b449ae65205fdcbf2c48...