[Interpreter] Add CallRuntime support to the interpreter.

[Interpreter] Add CallRuntime support to the interpreter.

Adds support for calling runtime functions from the interpreter. Adds the
CallRuntime bytecode which takes a Runtime::FunctionId of the function to call
and the arguments in sequential registers. Adds a InterpreterCEntry builtin
to enable the interpreter to enter C++ code based on the functionId.

Also renames Builtin::PushArgsAndCall to Builtin::InterpreterPushArgsAndCall
and groups all the interpreter builtins together.

BUG=v8:4280
LOG=N

Committed: https://crrev.com/75f6ad74b2c0fe2e5dec7110d076d892cfbb6b69
Cr-Commit-Position: refs/heads/master@{#31089}

[rmcilroy, 2015-09-24 16:27:21]

Patchset #1 (id:1) has been deleted

[rmcilroy, 2015-09-24 16:28:21]

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

[rmcilroy, 2015-09-24 16:28:22]

Benedikt, Orion, could you please take a look? Please let me know if you're
happy with the approach and I'll port to other architectures.

[Yang, 2015-09-24 16:57:20]

On 2015/09/24 16:28:22, rmcilroy wrote:
> Benedikt, Orion, could you please take a look? Please let me know if you're
> happy with the approach and I'll port to other architectures.

src/snapshot lgtm

[Benedikt Meurer, 2015-09-24 17:55:48]

bmeurer@chromium.org changed reviewers:
+ mstarzinger@chromium.org

[Benedikt Meurer, 2015-09-24 17:55:48]

bmeurer@chromium.org changed required reviewers:
+ mstarzinger@chromium.org

[Benedikt Meurer, 2015-09-24 17:55:49]

Builtin part LGTM. Overall approach also looks reasonable, tho I guess you'll
need specialized byte codes for the most important runtime calls (generated by
desugaring).

[Benedikt Meurer, 2015-09-24 17:56:27]

+mstarzinger for graph builder and general review.

[oth, 2015-09-25 09:49:27]

LGTM.

https://codereview.chromium.org/1362383002/diff/20001/src/interpreter/interpr...
File src/interpreter/interpreter.cc (right):

https://codereview.chromium.org/1362383002/diff/20001/src/interpreter/interpr...
src/interpreter/interpreter.cc:367: Node* function_id = __
BytecodeOperandIdx(0);
A TODO for the wider operand(s) discussed for function_id.

[Michael Starzinger, 2015-09-25 11:23:26]

https://codereview.chromium.org/1362383002/diff/20001/src/x64/builtins-x64.cc
File src/x64/builtins-x64.cc (right):

https://codereview.chromium.org/1362383002/diff/20001/src/x64/builtins-x64.cc...
src/x64/builtins-x64.cc:823: const int kFunctionSizeLog2 = 2 + kPointerSizeLog2;
Hmm, I am not all too excited to have lookup in the kIntrinsicFunctions table in
generated code now. But I cannot think of another efficient way to pull this
off, so I am inclined to go with it.

https://codereview.chromium.org/1362383002/diff/20001/src/x64/builtins-x64.cc...
src/x64/builtins-x64.cc:888: __ bind(&exception_returned);
I am not too happy about duplicating the CEntryStub.

Is there a fundamental reason we need a separate CEntryStub outside the dynamic
calculation of the C-Function entry address? Would it be possible to use the
normal CEntryStub and just do the entry-address calculation before somehow? Or
am I missing something?

[rmcilroy, 2015-09-28 16:13:43]

Patchset #2 (id:40001) has been deleted

[rmcilroy, 2015-09-28 16:20:48]

Reworked the code to avoid the need for a new builtin, PTAL.

https://codereview.chromium.org/1362383002/diff/20001/src/interpreter/interpr...
File src/interpreter/interpreter.cc (right):

https://codereview.chromium.org/1362383002/diff/20001/src/interpreter/interpr...
src/interpreter/interpreter.cc:367: Node* function_id = __
BytecodeOperandIdx(0);
On 2015/09/25 09:49:27, oth wrote:
> A TODO for the wider operand(s) discussed for function_id.

Implemented as a wide operand now.

https://codereview.chromium.org/1362383002/diff/20001/src/x64/builtins-x64.cc
File src/x64/builtins-x64.cc (right):

https://codereview.chromium.org/1362383002/diff/20001/src/x64/builtins-x64.cc...
src/x64/builtins-x64.cc:823: const int kFunctionSizeLog2 = 2 + kPointerSizeLog2;
On 2015/09/25 11:23:26, Michael Starzinger wrote:
> Hmm, I am not all too excited to have lookup in the kIntrinsicFunctions table
in
> generated code now. But I cannot think of another efficient way to pull this
> off, so I am inclined to go with it.

Acknowledged. I can't think of a better way either.

https://codereview.chromium.org/1362383002/diff/20001/src/x64/builtins-x64.cc...
src/x64/builtins-x64.cc:888: __ bind(&exception_returned);
On 2015/09/25 11:23:26, Michael Starzinger wrote:
> I am not too happy about duplicating the CEntryStub.
> 
> Is there a fundamental reason we need a separate CEntryStub outside the
dynamic
> calculation of the C-Function entry address? Would it be possible to use the
> normal CEntryStub and just do the entry-address calculation before somehow? Or
> am I missing something?

Very good point. The missing thing in CEntryStub was to have the argv already in
a register (rather than trying to calculate it's location on the stack). I've
added an option for this to CEntryStub now and moved the entry-address
calculation into interpreter-assembler, so there is now no need for a new
builtin (the only remaining builtin changes are the renaming of the already
existing PushArgsAndCall builtin. WDYT?

https://codereview.chromium.org/1362383002/diff/60001/src/runtime/runtime.cc
File src/runtime/runtime.cc (right):

https://codereview.chromium.org/1362383002/diff/60001/src/runtime/runtime.cc#...
src/runtime/runtime.cc:114: }
Note: To get this working on the simulator I've needed to make a duplicate
intrinsics table with redirected entry addresses (i.e., they point to the arm
software-interrupt handler which then transitions from the simulator to native
C++ implementation). The only other options I could think of would have been
really invasive to non-simulator code, so I think this is best since it only
does this duplicate when the interpreter is being used, and is running on a
simulator. Happy to discuss other options though.

[rmcilroy, 2015-09-28 16:43:55]

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

[commit-bot: I haz the power, 2015-09-28 16:44:25]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1362383002/60001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1362383002/60001

[commit-bot: I haz the power, 2015-09-28 16:58:16]

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

[commit-bot: I haz the power, 2015-09-28 16:58:17]

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

[Michael Starzinger, 2015-09-29 08:28:34]

LGTM, just nits and minor comments left. I like this approach much more as
opposed to duplicating the CEntry stub logic. Thanks for going the extra mile
here!

https://codereview.chromium.org/1362383002/diff/60001/src/builtins.h
File src/builtins.h (right):

https://codereview.chromium.org/1362383002/diff/60001/src/builtins.h#newcode306
src/builtins.h:306: static void Generate_InterpreterCEntry(MacroAssembler*
masm);
nit: The fourth generator function no longer exists, let's drop the declaration.

https://codereview.chromium.org/1362383002/diff/60001/src/compiler/interprete...
File src/compiler/interpreter-assembler.cc (right):

https://codereview.chromium.org/1362383002/diff/60001/src/compiler/interprete...
src/compiler/interpreter-assembler.cc:355: Callable builtin =
CodeFactory::InterpreterCEntry(isolate());
nit: This is no longer a "builtin", should we just use "callable" for this local
variable throughout the file for consistency and to avoid confusion?

https://codereview.chromium.org/1362383002/diff/60001/src/ia32/interface-desc...
File src/ia32/interface-descriptors-ia32.cc (right):

https://codereview.chromium.org/1362383002/diff/60001/src/ia32/interface-desc...
src/ia32/interface-descriptors-ia32.cc:406: eax,  // argument count (not
including receiver)
nit: This comment seems to be out of sync with other architecture ports, is that
on purpose?

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

https://codereview.chromium.org/1362383002/diff/60001/src/interpreter/bytecod...
src/interpreter/bytecode-generator.cc:478: DCHECK(arg.index() - i ==
first_arg.index());
nit: DCHECK_EQ here?

https://codereview.chromium.org/1362383002/diff/60001/src/runtime/runtime.cc
File src/runtime/runtime.cc (right):

https://codereview.chromium.org/1362383002/diff/60001/src/runtime/runtime.cc#...
src/runtime/runtime.cc:105: if (!kRedirectedIntrinsicFunctions) {
This is not thread-safe when multiple isolates are spinning up at the same time.
It's probably OK and nothing actionable at this time, but TSAN might come back
to you about this one.

https://codereview.chromium.org/1362383002/diff/60001/src/runtime/runtime.cc#...
src/runtime/runtime.cc:107: malloc(sizeof(kIntrinsicFunctions)));
Hmm, allocated but never freed AFAICT. How about we leave a TODO here that this
should eventually be moved into the Isolate instead?

https://codereview.chromium.org/1362383002/diff/60001/src/runtime/runtime.cc#...
src/runtime/runtime.cc:114: }
On 2015/09/28 16:20:47, rmcilroy wrote:
> Note: To get this working on the simulator I've needed to make a duplicate
> intrinsics table with redirected entry addresses (i.e., they point to the arm
> software-interrupt handler which then transitions from the simulator to native
> C++ implementation). The only other options I could think of would have been
> really invasive to non-simulator code, so I think this is best since it only
> does this duplicate when the interpreter is being used, and is running on a
> simulator. Happy to discuss other options though.

Acknowledged. I'm fine with this, just the mechanics mentioned in the comments
above might need addressing, TODOs and follow-up CL is fine as well.

[oth, 2015-09-29 09:33:36]

Looks good on the interpreter front.

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

https://codereview.chromium.org/1362383002/diff/60001/src/interpreter/bytecod...
src/interpreter/bytecode-generator.cc:483: DCHECK(expr->function()->result_size
<= 1);
nit: DCHECK_LE

https://codereview.chromium.org/1362383002/diff/60001/src/runtime/runtime.cc
File src/runtime/runtime.cc (right):

https://codereview.chromium.org/1362383002/diff/60001/src/runtime/runtime.cc#...
src/runtime/runtime.cc:110: for (int i = 0; i < sizeof(kIntrinsicFunctions) /
sizeof(Function); i++) {
nit: arraysize()

https://codereview.chromium.org/1362383002/diff/60001/test/unittests/interpre...
File test/unittests/interpreter/bytecode-array-builder-unittest.cc (right):

https://codereview.chromium.org/1362383002/diff/60001/test/unittests/interpre...
test/unittests/interpreter/bytecode-array-builder-unittest.cc:54:
builder.CallRuntime(Runtime::kIsArray, reg, 0);
Curious why this works with arg_count == 0? Runtime_IsArray DCHECKs args_count
== 1.

[rmcilroy, 2015-10-01 15:01:51]

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

[commit-bot: I haz the power, 2015-10-01 15:02:19]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1362383002/80001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1362383002/80001

[commit-bot: I haz the power, 2015-10-01 15:07:44]

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

[commit-bot: I haz the power, 2015-10-01 15:07:45]

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

[rmcilroy, 2015-10-01 16:29:42]

Patchset #3 (id:80001) has been deleted

[rmcilroy, 2015-10-01 17:02:45]

Comments addressed, PTAL, thanks.

https://codereview.chromium.org/1362383002/diff/60001/src/builtins.h
File src/builtins.h (right):

https://codereview.chromium.org/1362383002/diff/60001/src/builtins.h#newcode306
src/builtins.h:306: static void Generate_InterpreterCEntry(MacroAssembler*
masm);
On 2015/09/29 08:28:34, Michael Starzinger wrote:
> nit: The fourth generator function no longer exists, let's drop the
declaration.

Done.

https://codereview.chromium.org/1362383002/diff/60001/src/compiler/interprete...
File src/compiler/interpreter-assembler.cc (right):

https://codereview.chromium.org/1362383002/diff/60001/src/compiler/interprete...
src/compiler/interpreter-assembler.cc:355: Callable builtin =
CodeFactory::InterpreterCEntry(isolate());
On 2015/09/29 08:28:34, Michael Starzinger wrote:
> nit: This is no longer a "builtin", should we just use "callable" for this
local
> variable throughout the file for consistency and to avoid confusion?

Done.

https://codereview.chromium.org/1362383002/diff/60001/src/ia32/interface-desc...
File src/ia32/interface-descriptors-ia32.cc (right):

https://codereview.chromium.org/1362383002/diff/60001/src/ia32/interface-desc...
src/ia32/interface-descriptors-ia32.cc:406: eax,  // argument count (not
including receiver)
On 2015/09/29 08:28:34, Michael Starzinger wrote:
> nit: This comment seems to be out of sync with other architecture ports, is
that
> on purpose?

The original comment was wrong, I meant to update all other architectures to be
like this but missed some - done now.

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

https://codereview.chromium.org/1362383002/diff/60001/src/interpreter/bytecod...
src/interpreter/bytecode-generator.cc:478: DCHECK(arg.index() - i ==
first_arg.index());
On 2015/09/29 08:28:34, Michael Starzinger wrote:
> nit: DCHECK_EQ here?

Done.

https://codereview.chromium.org/1362383002/diff/60001/src/interpreter/bytecod...
src/interpreter/bytecode-generator.cc:483: DCHECK(expr->function()->result_size
<= 1);
On 2015/09/29 09:33:36, oth wrote:
> nit: DCHECK_LE

Done.

https://codereview.chromium.org/1362383002/diff/60001/src/runtime/runtime.cc
File src/runtime/runtime.cc (right):

https://codereview.chromium.org/1362383002/diff/60001/src/runtime/runtime.cc#...
src/runtime/runtime.cc:105: if (!kRedirectedIntrinsicFunctions) {
On 2015/09/29 08:28:34, Michael Starzinger wrote:
> This is not thread-safe when multiple isolates are spinning up at the same
time.
> It's probably OK and nothing actionable at this time, but TSAN might come back
> to you about this one.

Put this on the isolate in RuntimeState as disscussed offline. This should
address the threading issues.

https://codereview.chromium.org/1362383002/diff/60001/src/runtime/runtime.cc#...
src/runtime/runtime.cc:107: malloc(sizeof(kIntrinsicFunctions)));
On 2015/09/29 08:28:34, Michael Starzinger wrote:
> Hmm, allocated but never freed AFAICT. How about we leave a TODO here that
this
> should eventually be moved into the Isolate instead?

Put this on the isolate in RuntimeState as disscussed offline. This should
address the freeing issues.

https://codereview.chromium.org/1362383002/diff/60001/src/runtime/runtime.cc#...
src/runtime/runtime.cc:110: for (int i = 0; i < sizeof(kIntrinsicFunctions) /
sizeof(Function); i++) {
On 2015/09/29 09:33:36, oth wrote:
> nit: arraysize()

Done.

https://codereview.chromium.org/1362383002/diff/60001/src/runtime/runtime.cc#...
src/runtime/runtime.cc:114: }
On 2015/09/29 08:28:34, Michael Starzinger wrote:
> On 2015/09/28 16:20:47, rmcilroy wrote:
> > Note: To get this working on the simulator I've needed to make a duplicate
> > intrinsics table with redirected entry addresses (i.e., they point to the
arm
> > software-interrupt handler which then transitions from the simulator to
native
> > C++ implementation). The only other options I could think of would have been
> > really invasive to non-simulator code, so I think this is best since it only
> > does this duplicate when the interpreter is being used, and is running on a
> > simulator. Happy to discuss other options though.
> 
> Acknowledged. I'm fine with this, just the mechanics mentioned in the comments
> above might need addressing, TODOs and follow-up CL is fine as well.

Acknowledged.

https://codereview.chromium.org/1362383002/diff/60001/test/unittests/interpre...
File test/unittests/interpreter/bytecode-array-builder-unittest.cc (right):

https://codereview.chromium.org/1362383002/diff/60001/test/unittests/interpre...
test/unittests/interpreter/bytecode-array-builder-unittest.cc:54:
builder.CallRuntime(Runtime::kIsArray, reg, 0);
On 2015/09/29 09:33:36, oth wrote:
> Curious why this works with arg_count == 0? Runtime_IsArray DCHECKs args_count
> == 1.

Because the code generated by this test is never actually run so IsArray never
gets called (a bunch of other bytecodes in this tests aren't really runnable
either, it is just a test that the builder does what we expect). Updated to 1
anyway.

[rmcilroy, 2015-10-01 17:03:13]

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

[commit-bot: I haz the power, 2015-10-01 17:03:28]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1362383002/120001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1362383002/120001

[rmcilroy, 2015-10-01 17:04:10]

Patchset #4 (id:120001) has been deleted

[rmcilroy, 2015-10-01 17:04:15]

Patchset #4 (id:120001) has been deleted

[rmcilroy, 2015-10-01 17:05:29]

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

[commit-bot: I haz the power, 2015-10-01 17:05:52]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1362383002/140001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1362383002/140001

[commit-bot: I haz the power, 2015-10-01 17:15:58]

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

[commit-bot: I haz the power, 2015-10-01 17:15:59]

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

[Michael Starzinger, 2015-10-01 17:43:48]

https://codereview.chromium.org/1362383002/diff/60001/src/runtime/runtime.cc
File src/runtime/runtime.cc (right):

https://codereview.chromium.org/1362383002/diff/60001/src/runtime/runtime.cc#...
src/runtime/runtime.cc:105: if (!kRedirectedIntrinsicFunctions) {
On 2015/10/01 17:02:45, rmcilroy wrote:
> On 2015/09/29 08:28:34, Michael Starzinger wrote:
> > This is not thread-safe when multiple isolates are spinning up at the same
> time.
> > It's probably OK and nothing actionable at this time, but TSAN might come
back
> > to you about this one.
> 
> Put this on the isolate in RuntimeState as disscussed offline. This should
> address the threading issues.

Acknowledged. Looks good.

https://codereview.chromium.org/1362383002/diff/60001/src/runtime/runtime.cc#...
src/runtime/runtime.cc:107: malloc(sizeof(kIntrinsicFunctions)));
On 2015/10/01 17:02:45, rmcilroy wrote:
> On 2015/09/29 08:28:34, Michael Starzinger wrote:
> > Hmm, allocated but never freed AFAICT. How about we leave a TODO here that
> this
> > should eventually be moved into the Isolate instead?
> 
> Put this on the isolate in RuntimeState as disscussed offline. This should
> address the freeing issues.

Acknowledged. Looks good.

[Michael Starzinger, 2015-10-01 17:45:17]

https://codereview.chromium.org/1362383002/diff/140001/src/runtime/runtime.h
File src/runtime/runtime.h (left):

https://codereview.chromium.org/1362383002/diff/140001/src/runtime/runtime.h#...
src/runtime/runtime.h:1113: class RuntimeState {
Thanks for moving this down, this "gap" between the comment above and the class
below made me uneasy everytime I scrolled past it. :)

[rmcilroy, 2015-10-01 20:44:25]

https://codereview.chromium.org/1362383002/diff/140001/src/runtime/runtime.h
File src/runtime/runtime.h (left):

https://codereview.chromium.org/1362383002/diff/140001/src/runtime/runtime.h#...
src/runtime/runtime.h:1113: class RuntimeState {
On 2015/10/01 17:45:17, Michael Starzinger wrote:
> Thanks for moving this down, this "gap" between the comment above and the
class
> below made me uneasy everytime I scrolled past it. :)

Ack :)

[rmcilroy, 2015-10-01 20:44:31]

The CQ bit was checked by rmcilroy@chromium.org

[rmcilroy, 2015-10-01 20:44:31]

The patchset sent to the CQ was uploaded after l-g-t-m from
bmeurer@chromium.org, oth@chromium.org, yangguo@chromium.org,
mstarzinger@chromium.org
Link to the patchset: https://codereview.chromium.org/1362383002/#ps160001
(title: "Fix typo")

[commit-bot: I haz the power, 2015-10-01 20:44:43]

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

[commit-bot: I haz the power, 2015-10-01 20:46:57]

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

[commit-bot: I haz the power, 2015-10-01 20:46:58]

Try jobs failed on following builders:
  v8_win64_rel on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_win64_rel/builds/9222)
  v8_win_rel on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_win_rel/builds/10248)

[rmcilroy, 2015-10-02 06:58:07]

The CQ bit was checked by rmcilroy@chromium.org

[rmcilroy, 2015-10-02 06:58:08]

The patchset sent to the CQ was uploaded after l-g-t-m from
bmeurer@chromium.org, oth@chromium.org, mstarzinger@chromium.org,
yangguo@chromium.org
Link to the patchset: https://codereview.chromium.org/1362383002/#ps180001
(title: "Rebased")

[commit-bot: I haz the power, 2015-10-02 06:58:29]

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

[commit-bot: I haz the power, 2015-10-02 07:25:44]

Committed patchset #6 (id:180001)

[commit-bot: I haz the power, 2015-10-02 07:26:04]

Patchset 6 (id:??) landed as
https://crrev.com/40e8424b744f8b6e3e1d93e20f23487419911dfc
Cr-Commit-Position: refs/heads/master@{#31064}

[rmcilroy, 2015-10-02 09:20:39]

A revert of this CL (patchset #6 id:180001) has been created in
https://codereview.chromium.org/1387543002/ by rmcilroy@chromium.org.

The reason for reverting is: Broke Arm64 bot (CEntry stub is trying to pop
arguments off stack when argv_in_reg, so I need to fix this)..

[rmcilroy, 2015-10-02 11:39:49]

Mich: I've uploaded a fix to the issue which caused the revert - it turns out I
had forgotten CEntry stub would try to pop argc, which we don't want to do in
the interpreter. I've corrected this now and added a --debug_code check to
ensure our stack pointer is always the same before and after calls in the
interpreter. The changes are between patchset 6 and patchset 7. PTAL, thanks.

[Michael Starzinger, 2015-10-02 12:43:31]

LGTM in patch set 7.

[rmcilroy, 2015-10-02 12:43:54]

The CQ bit was checked by rmcilroy@chromium.org

[rmcilroy, 2015-10-02 12:43:54]

The patchset sent to the CQ was uploaded after l-g-t-m from
bmeurer@chromium.org, oth@chromium.org, yangguo@chromium.org
Link to the patchset: https://codereview.chromium.org/1362383002/#ps200001
(title: "Ensure stack is correct after centry in interpreter")

[commit-bot: I haz the power, 2015-10-02 12:44:13]

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

[commit-bot: I haz the power, 2015-10-02 12:49:44]

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

[commit-bot: I haz the power, 2015-10-02 12:49:45]

Try jobs failed on following builders:
  v8_linux_mips64el_compile_rel on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux_mips64el_compile_r...)

[rmcilroy, 2015-10-02 13:46:35]

The CQ bit was checked by rmcilroy@chromium.org

[rmcilroy, 2015-10-02 13:46:36]

The patchset sent to the CQ was uploaded after l-g-t-m from
bmeurer@chromium.org, oth@chromium.org, mstarzinger@chromium.org,
yangguo@chromium.org
Link to the patchset: https://codereview.chromium.org/1362383002/#ps220001
(title: "Fix gcc compiler errors")

[commit-bot: I haz the power, 2015-10-02 13:46:59]

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

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

Committed patchset #8 (id:220001)

[commit-bot: I haz the power, 2015-10-02 14:12:18]

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

[rmcilroy, 2015-10-02 15:11:10]

A revert of this CL (patchset #8 id:220001) has been created in
https://codereview.chromium.org/1379933003/ by rmcilroy@chromium.org.

The reason for reverting is: Now breaking arm32 debug bot (worked locally even
with --debug-code, so I'll need to figure out what's different on the bot).

[rmcilroy, 2015-10-02 17:29:58]

The CQ bit was checked by rmcilroy@chromium.org

[rmcilroy, 2015-10-02 17:29:59]

The patchset sent to the CQ was uploaded after l-g-t-m from
bmeurer@chromium.org, oth@chromium.org, mstarzinger@chromium.org,
yangguo@chromium.org
Link to the patchset: https://codereview.chromium.org/1362383002/#ps240001
(title: "Fix arm32 debug build check errors.")

[commit-bot: I haz the power, 2015-10-02 17:30:20]

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

[rmcilroy, 2015-10-02 17:31:18]

Let's try this again... Minor tweak which fixes the arm32 check error on the
debug bot, so I'll try landing again.

[commit-bot: I haz the power, 2015-10-02 17:32:33]

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

[commit-bot: I haz the power, 2015-10-02 17:32:34]

Try jobs failed on following builders:
  v8_linux64_asan_rel on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_asan_rel/builds/...)
  v8_linux_mips64el_compile_rel on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux_mips64el_compile_r...)
  v8_linux_nodcheck_rel on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux_nodcheck_rel/build...)

[rmcilroy, 2015-10-02 17:37:57]

The CQ bit was checked by rmcilroy@chromium.org

[commit-bot: I haz the power, 2015-10-02 17:38:27]

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

[commit-bot: I haz the power, 2015-10-02 17:39:58]

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

[commit-bot: I haz the power, 2015-10-02 17:39:59]

Try jobs failed on following builders:
  v8_linux64_rel on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_rel/builds/10288)
  v8_linux_arm64_rel on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux_arm64_rel/builds/1...)
  v8_linux_dbg on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux_dbg/builds/9242)

[rmcilroy, 2015-10-02 17:51:01]

The CQ bit was checked by rmcilroy@chromium.org

[commit-bot: I haz the power, 2015-10-02 17:51:21]

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

[commit-bot: I haz the power, 2015-10-02 18:13:45]

Committed patchset #9 (id:240001)

[commit-bot: I haz the power, 2015-10-02 18:14:14]

Patchset 9 (id:??) landed as
https://crrev.com/75f6ad74b2c0fe2e5dec7110d076d892cfbb6b69
Cr-Commit-Position: refs/heads/master@{#31089}