[compiler] Sidestep optimizing of generator resumers.

[compiler] Sidestep optimizing of generator resumers.

This ensures our optimizing compilers as well as the interpreter are
never tasked with compiling the generator-resuming builtin methods. The
corresponding intrinsics for those methods are not supported and it is
not possible to provide a C++ reference implementation for them. We do
this by assigning builtin function ids to them that we can recognize
during the compiler dispatch.

Note that this also affects the interpreter, because methods having a
builtin function id assigned are not interpreted ({function_data} field
is overlapping). If this ever changes we can still do an early check in
the compiler dispatch (similar to the optimizing compilers) easily.

This applies to the following methods:
- Generator.prototype.next (calls Runtime_GeneratorNext).
- Generator.prototype.return (calls Runtime_GeneratorReturn).
- Generator.prototype.throw (calls Runtime_GeneratorThrow).

R=neis@chromium.org
BUG=v8:4681
LOG=n

Committed: https://crrev.com/855176533c6e64d31b789c85dc86ab60ad5bfc70
Cr-Commit-Position: refs/heads/master@{#34675}

[Michael Starzinger, 2016-03-10 12:30:37]

Description was changed from

==========
[compiler] Sidestep optimizing of generator resumers.

The ensures our optimizing compilers as well as the interpreter are
never tasked with comping the generator resuming builting methods. The
corresponding intrinsics for those methods are not supported and it is
not possible to provide a C++ reference implementation for them. We do
this by assigning builtin function ids to them that we can recognize
during the compiler dispatch.

This applies to the following methods:
- Generator.prototype.next (calls Runtime_GeneratorNext).
- Generator.prototype.return (calls Runtime_GeneratorReturn).
- Generator.prototype.throw (calls Runtime_GeneratorThrow).

R=neis@chromium.org,rmcilroy@chromium.org
BUG=v8:4681
LOG=n
==========

to

==========
[compiler] Sidestep optimizing of generator resumers.

The ensures our optimizing compilers as well as the interpreter are
never tasked with comping the generator resuming builting methods. The
corresponding intrinsics for those methods are not supported and it is
not possible to provide a C++ reference implementation for them. We do
this by assigning builtin function ids to them that we can recognize
during the compiler dispatch.

This applies to the following methods:
- Generator.prototype.next (calls Runtime_GeneratorNext).
- Generator.prototype.return (calls Runtime_GeneratorReturn).
- Generator.prototype.throw (calls Runtime_GeneratorThrow).

R=neis@chromium.org
BUG=v8:4681
LOG=n
==========

[Michael Starzinger, 2016-03-10 12:31:13]

Georg: PTAL at the implementation.
Ross: FYI about interpreter.

[Michael Starzinger, 2016-03-10 12:35:26]

Description was changed from

==========
[compiler] Sidestep optimizing of generator resumers.

The ensures our optimizing compilers as well as the interpreter are
never tasked with comping the generator resuming builting methods. The
corresponding intrinsics for those methods are not supported and it is
not possible to provide a C++ reference implementation for them. We do
this by assigning builtin function ids to them that we can recognize
during the compiler dispatch.

This applies to the following methods:
- Generator.prototype.next (calls Runtime_GeneratorNext).
- Generator.prototype.return (calls Runtime_GeneratorReturn).
- Generator.prototype.throw (calls Runtime_GeneratorThrow).

R=neis@chromium.org
BUG=v8:4681
LOG=n
==========

to

==========
[compiler] Sidestep optimizing of generator resumers.

This ensures our optimizing compilers as well as the interpreter are
never tasked with compiling the generator resuming builtin methods. The
corresponding intrinsics for those methods are not supported and it is
not possible to provide a C++ reference implementation for them. We do
this by assigning builtin function ids to them that we can recognize
during the compiler dispatch.

This applies to the following methods:
- Generator.prototype.next (calls Runtime_GeneratorNext).
- Generator.prototype.return (calls Runtime_GeneratorReturn).
- Generator.prototype.throw (calls Runtime_GeneratorThrow).

R=neis@chromium.org
BUG=v8:4681
LOG=n
==========

[neis, 2016-03-10 12:50:53]

Thanks, LGTM.

Can you just add a comment saying where the bailout in the interpreter happens?
(And there's a few typos in the CL description).

[rmcilroy, 2016-03-10 12:50:56]

Great, approach LGTM if Georg agrees.

https://codereview.chromium.org/1779123003/diff/1/test/mjsunit/mjsunit.status
File test/mjsunit/mjsunit.status (right):

https://codereview.chromium.org/1779123003/diff/1/test/mjsunit/mjsunit.status...
test/mjsunit/mjsunit.status:827: 'es6/classes-subclass-builtins': [FAIL],
Still some failing tests - is still something we are missing here?

[Michael Starzinger, 2016-03-10 13:05:17]

Description was changed from

==========
[compiler] Sidestep optimizing of generator resumers.

This ensures our optimizing compilers as well as the interpreter are
never tasked with compiling the generator resuming builtin methods. The
corresponding intrinsics for those methods are not supported and it is
not possible to provide a C++ reference implementation for them. We do
this by assigning builtin function ids to them that we can recognize
during the compiler dispatch.

This applies to the following methods:
- Generator.prototype.next (calls Runtime_GeneratorNext).
- Generator.prototype.return (calls Runtime_GeneratorReturn).
- Generator.prototype.throw (calls Runtime_GeneratorThrow).

R=neis@chromium.org
BUG=v8:4681
LOG=n
==========

to

==========
[compiler] Sidestep optimizing of generator resumers.

This ensures our optimizing compilers as well as the interpreter are
never tasked with compiling the generator resuming builtin methods. The
corresponding intrinsics for those methods are not supported and it is
not possible to provide a C++ reference implementation for them. We do
this by assigning builtin function ids to them that we can recognize
during the compiler dispatch.

Note that this also affects the interpreter, because methods having a
builtin function id assigned are not interpreted ({function_data} field
is overlapping). If this ever changes we can still do an early dispatch
in the compiler dispatch (similar to the optimizing compilers) easily.

This applies to the following methods:
- Generator.prototype.next (calls Runtime_GeneratorNext).
- Generator.prototype.return (calls Runtime_GeneratorReturn).
- Generator.prototype.throw (calls Runtime_GeneratorThrow).

R=neis@chromium.org
BUG=v8:4681
LOG=n
==========

[Michael Starzinger, 2016-03-10 13:06:37]

Thanks. Comment added to CL description. Typos fixed (hopefully). Preparing to
land.

https://codereview.chromium.org/1779123003/diff/1/test/mjsunit/mjsunit.status
File test/mjsunit/mjsunit.status (right):

https://codereview.chromium.org/1779123003/diff/1/test/mjsunit/mjsunit.status...
test/mjsunit/mjsunit.status:827: 'es6/classes-subclass-builtins': [FAIL],
On 2016/03/10 12:50:55, rmcilroy wrote:
> Still some failing tests - is still something we are missing here?

Acknowledged. Yes, I looked at a handful and they all run into the UNREACHABLE
in BytecodeGenerator::VisitYield. Needs investigation. I am on it. Stay tuned!
:)

[Michael Starzinger, 2016-03-10 13:08:24]

Description was changed from

==========
[compiler] Sidestep optimizing of generator resumers.

This ensures our optimizing compilers as well as the interpreter are
never tasked with compiling the generator resuming builtin methods. The
corresponding intrinsics for those methods are not supported and it is
not possible to provide a C++ reference implementation for them. We do
this by assigning builtin function ids to them that we can recognize
during the compiler dispatch.

Note that this also affects the interpreter, because methods having a
builtin function id assigned are not interpreted ({function_data} field
is overlapping). If this ever changes we can still do an early dispatch
in the compiler dispatch (similar to the optimizing compilers) easily.

This applies to the following methods:
- Generator.prototype.next (calls Runtime_GeneratorNext).
- Generator.prototype.return (calls Runtime_GeneratorReturn).
- Generator.prototype.throw (calls Runtime_GeneratorThrow).

R=neis@chromium.org
BUG=v8:4681
LOG=n
==========

to

==========
[compiler] Sidestep optimizing of generator resumers.

This ensures our optimizing compilers as well as the interpreter are
never tasked with compiling the generator-resuming builtin methods. The
corresponding intrinsics for those methods are not supported and it is
not possible to provide a C++ reference implementation for them. We do
this by assigning builtin function ids to them that we can recognize
during the compiler dispatch.

Note that this also affects the interpreter, because methods having a
builtin function id assigned are not interpreted ({function_data} field
is overlapping). If this ever changes we can still do an early check in
the compiler dispatch (similar to the optimizing compilers) easily.

This applies to the following methods:
- Generator.prototype.next (calls Runtime_GeneratorNext).
- Generator.prototype.return (calls Runtime_GeneratorReturn).
- Generator.prototype.throw (calls Runtime_GeneratorThrow).

R=neis@chromium.org
BUG=v8:4681
LOG=n
==========

[Michael Starzinger, 2016-03-10 14:01:55]

The CQ bit was checked by mstarzinger@chromium.org

[Michael Starzinger, 2016-03-10 14:01:56]

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/1779123003/#ps40001
(title: "Rebased.")

[commit-bot: I haz the power, 2016-03-10 14:02:10]

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

[commit-bot: I haz the power, 2016-03-10 14:06:09]

Description was changed from

==========
[compiler] Sidestep optimizing of generator resumers.

This ensures our optimizing compilers as well as the interpreter are
never tasked with compiling the generator-resuming builtin methods. The
corresponding intrinsics for those methods are not supported and it is
not possible to provide a C++ reference implementation for them. We do
this by assigning builtin function ids to them that we can recognize
during the compiler dispatch.

Note that this also affects the interpreter, because methods having a
builtin function id assigned are not interpreted ({function_data} field
is overlapping). If this ever changes we can still do an early check in
the compiler dispatch (similar to the optimizing compilers) easily.

This applies to the following methods:
- Generator.prototype.next (calls Runtime_GeneratorNext).
- Generator.prototype.return (calls Runtime_GeneratorReturn).
- Generator.prototype.throw (calls Runtime_GeneratorThrow).

R=neis@chromium.org
BUG=v8:4681
LOG=n
==========

to

==========
[compiler] Sidestep optimizing of generator resumers.

This ensures our optimizing compilers as well as the interpreter are
never tasked with compiling the generator-resuming builtin methods. The
corresponding intrinsics for those methods are not supported and it is
not possible to provide a C++ reference implementation for them. We do
this by assigning builtin function ids to them that we can recognize
during the compiler dispatch.

Note that this also affects the interpreter, because methods having a
builtin function id assigned are not interpreted ({function_data} field
is overlapping). If this ever changes we can still do an early check in
the compiler dispatch (similar to the optimizing compilers) easily.

This applies to the following methods:
- Generator.prototype.next (calls Runtime_GeneratorNext).
- Generator.prototype.return (calls Runtime_GeneratorReturn).
- Generator.prototype.throw (calls Runtime_GeneratorThrow).

R=neis@chromium.org
BUG=v8:4681
LOG=n
==========

[commit-bot: I haz the power, 2016-03-10 14:06:09]

Committed patchset #3 (id:40001)

[commit-bot: I haz the power, 2016-03-10 14:07:18]

Description was changed from

==========
[compiler] Sidestep optimizing of generator resumers.

This ensures our optimizing compilers as well as the interpreter are
never tasked with compiling the generator-resuming builtin methods. The
corresponding intrinsics for those methods are not supported and it is
not possible to provide a C++ reference implementation for them. We do
this by assigning builtin function ids to them that we can recognize
during the compiler dispatch.

Note that this also affects the interpreter, because methods having a
builtin function id assigned are not interpreted ({function_data} field
is overlapping). If this ever changes we can still do an early check in
the compiler dispatch (similar to the optimizing compilers) easily.

This applies to the following methods:
- Generator.prototype.next (calls Runtime_GeneratorNext).
- Generator.prototype.return (calls Runtime_GeneratorReturn).
- Generator.prototype.throw (calls Runtime_GeneratorThrow).

R=neis@chromium.org
BUG=v8:4681
LOG=n
==========

to

==========
[compiler] Sidestep optimizing of generator resumers.

This ensures our optimizing compilers as well as the interpreter are
never tasked with compiling the generator-resuming builtin methods. The
corresponding intrinsics for those methods are not supported and it is
not possible to provide a C++ reference implementation for them. We do
this by assigning builtin function ids to them that we can recognize
during the compiler dispatch.

Note that this also affects the interpreter, because methods having a
builtin function id assigned are not interpreted ({function_data} field
is overlapping). If this ever changes we can still do an early check in
the compiler dispatch (similar to the optimizing compilers) easily.

This applies to the following methods:
- Generator.prototype.next (calls Runtime_GeneratorNext).
- Generator.prototype.return (calls Runtime_GeneratorReturn).
- Generator.prototype.throw (calls Runtime_GeneratorThrow).

R=neis@chromium.org
BUG=v8:4681
LOG=n

Committed: https://crrev.com/855176533c6e64d31b789c85dc86ab60ad5bfc70
Cr-Commit-Position: refs/heads/master@{#34675}
==========

[commit-bot: I haz the power, 2016-03-10 14:07:19]

Patchset 3 (id:??) landed as
https://crrev.com/855176533c6e64d31b789c85dc86ab60ad5bfc70
Cr-Commit-Position: refs/heads/master@{#34675}