[stubs] A new approach to TF stubs

[stubs] A new approach to TF stubs

* Add a sibling interface to InterpreterAssembler called
  CodeStubAssembler which provides a wrapper around the
  RawMachineAssembler and is intented to make it easy to build
  efficient cross-platform code stubs. Much of the implementation
  of CodeStubAssembler is shamelessly stolen from the
  InterpreterAssembler, and the idea is to eventually merge the
  two interfaces somehow, probably moving the
  InterpreterAssembler interface over to use the
  CodeStubAssembler. Short-term, however, the two interfaces
  shall remain decoupled to increase our velocity developing the
  two systems in parallel.
* Implement the StringLength stub in TurboFan with the new
  CodeStubAssembler. Replace and remove the old Hydrogen-stub
  version.
* Remove a whole slew of machinery to support JavaScript-style
  code stub generation, since it ultimately proved unwieldy,
  brittle and baroque. This cleanup includes removing the shared
  code stub context, several example stubs and a tangle of build
  file changes.

BUG=v8:4587
LOG=n

Committed: https://crrev.com/3e7e3ed726dd016dc6ae89803999a28fba2362c7
Cr-Commit-Position: refs/heads/master@{#32508}

[danno, 2015-11-30 08:23:20]

Description was changed from

==========
[stubs] A new approach to TF stubs

BUG=
==========

to

==========
[stubs] A new approach to TF stubs

* Add a sibling interface to InterpreterAssembler called
  CodeStubAssembler which provides a wrapper around the
  RawMachineAssembler and is intented to make it easy to build
  efficient cross-platform code stubs. Much of the implementation
  of CodeStubAssembler is shamelessly stolen from the
  InterpreterAssembler, and the idea is to eventually merge the
  two interfaces somehow, probably moving the
  InterpreterAssembler interface over to use the
  CodeStubAssembler. Short-term, however, the two interfaces
  shall remain decoupled to increase our velocity developing the
  two systems in parallel.
* Implement the StringLength in TurboFan with the new
  CodeStubAssembler. Replace and remove the old Hydrogen-stub
  base version.
* Remove a whole slough of machinery to support JavaScript-style
  code stub generaiton, since it ultimately proved unweildy,
  brittle and baroque. This cleanup includes removing the shared
  code stub context, several example stubs and a tangle of build
  file changes.

BUG=
==========

[danno, 2015-11-30 08:23:38]

Description was changed from

==========
[stubs] A new approach to TF stubs

* Add a sibling interface to InterpreterAssembler called
  CodeStubAssembler which provides a wrapper around the
  RawMachineAssembler and is intented to make it easy to build
  efficient cross-platform code stubs. Much of the implementation
  of CodeStubAssembler is shamelessly stolen from the
  InterpreterAssembler, and the idea is to eventually merge the
  two interfaces somehow, probably moving the
  InterpreterAssembler interface over to use the
  CodeStubAssembler. Short-term, however, the two interfaces
  shall remain decoupled to increase our velocity developing the
  two systems in parallel.
* Implement the StringLength in TurboFan with the new
  CodeStubAssembler. Replace and remove the old Hydrogen-stub
  base version.
* Remove a whole slough of machinery to support JavaScript-style
  code stub generaiton, since it ultimately proved unweildy,
  brittle and baroque. This cleanup includes removing the shared
  code stub context, several example stubs and a tangle of build
  file changes.

BUG=
==========

to

==========
[stubs] A new approach to TF stubs

* Add a sibling interface to InterpreterAssembler called
  CodeStubAssembler which provides a wrapper around the
  RawMachineAssembler and is intented to make it easy to build
  efficient cross-platform code stubs. Much of the implementation
  of CodeStubAssembler is shamelessly stolen from the
  InterpreterAssembler, and the idea is to eventually merge the
  two interfaces somehow, probably moving the
  InterpreterAssembler interface over to use the
  CodeStubAssembler. Short-term, however, the two interfaces
  shall remain decoupled to increase our velocity developing the
  two systems in parallel.
* Implement the StringLength in TurboFan with the new
  CodeStubAssembler. Replace and remove the old Hydrogen-stub
  base version.
* Remove a whole slough of machinery to support JavaScript-style
  code stub generation, since it ultimately proved unwieldy,
  brittle and baroque. This cleanup includes removing the shared
  code stub context, several example stubs and a tangle of build
  file changes.

BUG=
==========

[danno, 2015-11-30 13:46:31]

Description was changed from

==========
[stubs] A new approach to TF stubs

* Add a sibling interface to InterpreterAssembler called
  CodeStubAssembler which provides a wrapper around the
  RawMachineAssembler and is intented to make it easy to build
  efficient cross-platform code stubs. Much of the implementation
  of CodeStubAssembler is shamelessly stolen from the
  InterpreterAssembler, and the idea is to eventually merge the
  two interfaces somehow, probably moving the
  InterpreterAssembler interface over to use the
  CodeStubAssembler. Short-term, however, the two interfaces
  shall remain decoupled to increase our velocity developing the
  two systems in parallel.
* Implement the StringLength in TurboFan with the new
  CodeStubAssembler. Replace and remove the old Hydrogen-stub
  base version.
* Remove a whole slough of machinery to support JavaScript-style
  code stub generation, since it ultimately proved unwieldy,
  brittle and baroque. This cleanup includes removing the shared
  code stub context, several example stubs and a tangle of build
  file changes.

BUG=
==========

to

==========
[stubs] A new approach to TF stubs

* Add a sibling interface to InterpreterAssembler called
  CodeStubAssembler which provides a wrapper around the
  RawMachineAssembler and is intented to make it easy to build
  efficient cross-platform code stubs. Much of the implementation
  of CodeStubAssembler is shamelessly stolen from the
  InterpreterAssembler, and the idea is to eventually merge the
  two interfaces somehow, probably moving the
  InterpreterAssembler interface over to use the
  CodeStubAssembler. Short-term, however, the two interfaces
  shall remain decoupled to increase our velocity developing the
  two systems in parallel.
* Implement the StringLength stub in TurboFan with the new
  CodeStubAssembler. Replace and remove the old Hydrogen-stub
  base version.
* Remove a whole slough of machinery to support JavaScript-style
  code stub generation, since it ultimately proved unwieldy,
  brittle and baroque. This cleanup includes removing the shared
  code stub context, several example stubs and a tangle of build
  file changes.

BUG=
==========

[danno, 2015-12-01 10:00:49]

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

[danno, 2015-12-01 10:01:03]

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

[danno, 2015-12-01 10:01:11]

PTAL

[Michael Starzinger, 2015-12-01 18:06:54]

LGTM. Nice! I like this. Only nits.

https://codereview.chromium.org/1475953002/diff/180001/src/code-stubs.h
File src/code-stubs.h (right):

https://codereview.chromium.org/1475953002/diff/180001/src/code-stubs.h#newco...
src/code-stubs.h:538: compiler::CodeStubAssembler* assmebler) const = 0;
nit: s/assmebler/assembler/

https://codereview.chromium.org/1475953002/diff/180001/src/code-stubs.h#newco...
src/code-stubs.h:543: base::SmartPointer<compiler::CodeStubAssembler> asm_;
nit: It looks like this field is unused, can we drop it?

https://codereview.chromium.org/1475953002/diff/180001/src/compiler/code-stub...
File src/compiler/code-stub-assembler.h (right):

https://codereview.chromium.org/1475953002/diff/180001/src/compiler/code-stub...
src/compiler/code-stub-assembler.h:14: #include "src/interpreter/bytecodes.h"
nit: The "bytecodes.h" header shouldn't be needed here. Can we drop it just to
verify that it's not accidentally used here?

https://codereview.chromium.org/1475953002/diff/180001/src/compiler/code-stub...
src/compiler/code-stub-assembler.h:80: Graph* graph();
nit: Can we move this accessor down so that it lives together with the ones for
Zone and Isolate?

https://codereview.chromium.org/1475953002/diff/180001/src/compiler/pipeline.h
File src/compiler/pipeline.h (right):

https://codereview.chromium.org/1475953002/diff/180001/src/compiler/pipeline....
src/compiler/pipeline.h:33: // Run the pipeline on an code stub machine graph
and generate code.
nit: I know you didn't introduce this comment, but can we add a sentence along
the lines of "a valid schedule must be provided" here?

https://codereview.chromium.org/1475953002/diff/180001/src/compiler/raw-machi...
File src/compiler/raw-machine-assembler.cc (left):

https://codereview.chromium.org/1475953002/diff/180001/src/compiler/raw-machi...
src/compiler/raw-machine-assembler.cc:179: 
nit: Bring back empty newline just for consistency.

https://codereview.chromium.org/1475953002/diff/180001/src/interface-descript...
File src/interface-descriptors.h (right):

https://codereview.chromium.org/1475953002/diff/180001/src/interface-descript...
src/interface-descriptors.h:241: 
nit: Two empty newlines between top-level declarations.

https://codereview.chromium.org/1475953002/diff/180001/test/cctest/compiler/f...
File test/cctest/compiler/function-tester.h (right):

https://codereview.chromium.org/1475953002/diff/180001/test/cctest/compiler/f...
test/cctest/compiler/function-tester.h:38: // TODO(turbofan): generalize
FunctionTester to work with N arguments. Now, it
I think your change pretty much addresses this TODO. Should we remove the TODO?

https://codereview.chromium.org/1475953002/diff/180001/test/cctest/compiler/f...
test/cctest/compiler/function-tester.h:40: explicit FunctionTester(Graph* graph,
int param_count)
nit: No longer needs to be marked "explicit".

https://codereview.chromium.org/1475953002/diff/180001/test/cctest/compiler/f...
test/cctest/compiler/function-tester.h:47: explicit FunctionTester(const
CallInterfaceDescriptor& descriptor,
nit: Doesn't need to be marked "explicit".

https://codereview.chromium.org/1475953002/diff/180001/test/cctest/compiler/t...
File test/cctest/compiler/test-code-stub-assembler.cc (right):

https://codereview.chromium.org/1475953002/diff/180001/test/cctest/compiler/t...
test/cctest/compiler/test-code-stub-assembler.cc:14: static Isolate*
GetIsolate() {
nit: This is similar to what CcTest::InitIsolateOnce() does, can we use that
function instead?

https://codereview.chromium.org/1475953002/diff/180001/test/cctest/test-api.cc
File test/cctest/test-api.cc (right):

https://codereview.chromium.org/1475953002/diff/180001/test/cctest/test-api.c...
test/cctest/test-api.cc:13221: // Subtract one to compensate for the code stub
context that is always present
nit: Comment is out of date, I think we can just drop the comment now.

[adamk, 2015-12-01 19:27:30]

Excited to see code-stubs-hydrogen get a successor!

https://codereview.chromium.org/1475953002/diff/180001/src/compiler/code-stub...
File src/compiler/code-stub-assembler.h (right):

https://codereview.chromium.org/1475953002/diff/180001/src/compiler/code-stub...
src/compiler/code-stub-assembler.h:34: class CodeStubAssembler {
Would love to see documentation for this class somewhere (though I realize it's
at an early state). Is there a design sketch/doc for this approach  (maybe could
just be stolen from whatever we have for the InterpreterAssembler)?

[adamk, 2015-12-01 19:27:30]

Excited to see code-stubs-hydrogen get a successor!

https://codereview.chromium.org/1475953002/diff/180001/src/compiler/code-stub...
File src/compiler/code-stub-assembler.h (right):

https://codereview.chromium.org/1475953002/diff/180001/src/compiler/code-stub...
src/compiler/code-stub-assembler.h:34: class CodeStubAssembler {
Would love to see documentation for this class somewhere (though I realize it's
at an early state). Is there a design sketch/doc for this approach  (maybe could
just be stolen from whatever we have for the InterpreterAssembler)?

[danno, 2015-12-02 07:00:19]

Feedback addressed

https://codereview.chromium.org/1475953002/diff/180001/src/code-stubs.h
File src/code-stubs.h (right):

https://codereview.chromium.org/1475953002/diff/180001/src/code-stubs.h#newco...
src/code-stubs.h:538: compiler::CodeStubAssembler* assmebler) const = 0;
On 2015/12/01 18:06:53, Michael Starzinger wrote:
> nit: s/assmebler/assembler/

Done.

https://codereview.chromium.org/1475953002/diff/180001/src/code-stubs.h#newco...
src/code-stubs.h:543: base::SmartPointer<compiler::CodeStubAssembler> asm_;
On 2015/12/01 18:06:53, Michael Starzinger wrote:
> nit: It looks like this field is unused, can we drop it?

Done.

https://codereview.chromium.org/1475953002/diff/180001/src/compiler/code-stub...
File src/compiler/code-stub-assembler.h (right):

https://codereview.chromium.org/1475953002/diff/180001/src/compiler/code-stub...
src/compiler/code-stub-assembler.h:14: #include "src/interpreter/bytecodes.h"
On 2015/12/01 18:06:53, Michael Starzinger wrote:
> nit: The "bytecodes.h" header shouldn't be needed here. Can we drop it just to
> verify that it's not accidentally used here?

Done.

https://codereview.chromium.org/1475953002/diff/180001/src/compiler/code-stub...
src/compiler/code-stub-assembler.h:34: class CodeStubAssembler {
On 2015/12/01 19:27:30, adamk wrote:
> Would love to see documentation for this class somewhere (though I realize
it's
> at an early state). Is there a design sketch/doc for this approach  (maybe
could
> just be stolen from whatever we have for the InterpreterAssembler)?

Agreed. The InterpreterAssembler doesn't have any documentation to borrow, so
we'd need something new. I am not sure that document belongs in the code right
now, so I will start a separate document that gives an overview of the approach
and gives us a place to fill in details as more becomes clear.

https://codereview.chromium.org/1475953002/diff/180001/src/compiler/code-stub...
src/compiler/code-stub-assembler.h:80: Graph* graph();
On 2015/12/01 18:06:53, Michael Starzinger wrote:
> nit: Can we move this accessor down so that it lives together with the ones
for
> Zone and Isolate?

Done.

https://codereview.chromium.org/1475953002/diff/180001/src/compiler/pipeline.h
File src/compiler/pipeline.h (right):

https://codereview.chromium.org/1475953002/diff/180001/src/compiler/pipeline....
src/compiler/pipeline.h:33: // Run the pipeline on an code stub machine graph
and generate code.
On 2015/12/01 18:06:53, Michael Starzinger wrote:
> nit: I know you didn't introduce this comment, but can we add a sentence along
> the lines of "a valid schedule must be provided" here?

Done.

https://codereview.chromium.org/1475953002/diff/180001/src/compiler/raw-machi...
File src/compiler/raw-machine-assembler.cc (left):

https://codereview.chromium.org/1475953002/diff/180001/src/compiler/raw-machi...
src/compiler/raw-machine-assembler.cc:179: 
On 2015/12/01 18:06:53, Michael Starzinger wrote:
> nit: Bring back empty newline just for consistency.

Done.

https://codereview.chromium.org/1475953002/diff/180001/src/interface-descript...
File src/interface-descriptors.h (right):

https://codereview.chromium.org/1475953002/diff/180001/src/interface-descript...
src/interface-descriptors.h:241: 
On 2015/12/01 18:06:53, Michael Starzinger wrote:
> nit: Two empty newlines between top-level declarations.

Done.

https://codereview.chromium.org/1475953002/diff/180001/test/cctest/compiler/f...
File test/cctest/compiler/function-tester.h (right):

https://codereview.chromium.org/1475953002/diff/180001/test/cctest/compiler/f...
test/cctest/compiler/function-tester.h:38: // TODO(turbofan): generalize
FunctionTester to work with N arguments. Now, it
On 2015/12/01 18:06:53, Michael Starzinger wrote:
> I think your change pretty much addresses this TODO. Should we remove the
TODO?

Done.

https://codereview.chromium.org/1475953002/diff/180001/test/cctest/compiler/f...
test/cctest/compiler/function-tester.h:40: explicit FunctionTester(Graph* graph,
int param_count)
On 2015/12/01 18:06:53, Michael Starzinger wrote:
> nit: No longer needs to be marked "explicit".

Done.

https://codereview.chromium.org/1475953002/diff/180001/test/cctest/compiler/f...
test/cctest/compiler/function-tester.h:47: explicit FunctionTester(const
CallInterfaceDescriptor& descriptor,
On 2015/12/01 18:06:53, Michael Starzinger wrote:
> nit: Doesn't need to be marked "explicit".

Done.

https://codereview.chromium.org/1475953002/diff/180001/test/cctest/compiler/t...
File test/cctest/compiler/test-code-stub-assembler.cc (right):

https://codereview.chromium.org/1475953002/diff/180001/test/cctest/compiler/t...
test/cctest/compiler/test-code-stub-assembler.cc:14: static Isolate*
GetIsolate() {
On 2015/12/01 18:06:53, Michael Starzinger wrote:
> nit: This is similar to what CcTest::InitIsolateOnce() does, can we use that
> function instead?

Done.

https://codereview.chromium.org/1475953002/diff/180001/test/cctest/test-api.cc
File test/cctest/test-api.cc (right):

https://codereview.chromium.org/1475953002/diff/180001/test/cctest/test-api.c...
test/cctest/test-api.cc:13221: // Subtract one to compensate for the code stub
context that is always present
On 2015/12/01 18:06:53, Michael Starzinger wrote:
> nit: Comment is out of date, I think we can just drop the comment now.

Done.

[danno, 2015-12-02 07:04:41]

Description was changed from

==========
[stubs] A new approach to TF stubs

* Add a sibling interface to InterpreterAssembler called
  CodeStubAssembler which provides a wrapper around the
  RawMachineAssembler and is intented to make it easy to build
  efficient cross-platform code stubs. Much of the implementation
  of CodeStubAssembler is shamelessly stolen from the
  InterpreterAssembler, and the idea is to eventually merge the
  two interfaces somehow, probably moving the
  InterpreterAssembler interface over to use the
  CodeStubAssembler. Short-term, however, the two interfaces
  shall remain decoupled to increase our velocity developing the
  two systems in parallel.
* Implement the StringLength stub in TurboFan with the new
  CodeStubAssembler. Replace and remove the old Hydrogen-stub
  base version.
* Remove a whole slough of machinery to support JavaScript-style
  code stub generation, since it ultimately proved unwieldy,
  brittle and baroque. This cleanup includes removing the shared
  code stub context, several example stubs and a tangle of build
  file changes.

BUG=
==========

to

==========
[stubs] A new approach to TF stubs

* Add a sibling interface to InterpreterAssembler called
  CodeStubAssembler which provides a wrapper around the
  RawMachineAssembler and is intented to make it easy to build
  efficient cross-platform code stubs. Much of the implementation
  of CodeStubAssembler is shamelessly stolen from the
  InterpreterAssembler, and the idea is to eventually merge the
  two interfaces somehow, probably moving the
  InterpreterAssembler interface over to use the
  CodeStubAssembler. Short-term, however, the two interfaces
  shall remain decoupled to increase our velocity developing the
  two systems in parallel.
* Implement the StringLength stub in TurboFan with the new
  CodeStubAssembler. Replace and remove the old Hydrogen-stub
  base version.
* Remove a whole slew of machinery to support JavaScript-style
  code stub generation, since it ultimately proved unwieldy,
  brittle and baroque. This cleanup includes removing the shared
  code stub context, several example stubs and a tangle of build
  file changes.

BUG=
==========

[danno, 2015-12-02 07:19:28]

Description was changed from

==========
[stubs] A new approach to TF stubs

* Add a sibling interface to InterpreterAssembler called
  CodeStubAssembler which provides a wrapper around the
  RawMachineAssembler and is intented to make it easy to build
  efficient cross-platform code stubs. Much of the implementation
  of CodeStubAssembler is shamelessly stolen from the
  InterpreterAssembler, and the idea is to eventually merge the
  two interfaces somehow, probably moving the
  InterpreterAssembler interface over to use the
  CodeStubAssembler. Short-term, however, the two interfaces
  shall remain decoupled to increase our velocity developing the
  two systems in parallel.
* Implement the StringLength stub in TurboFan with the new
  CodeStubAssembler. Replace and remove the old Hydrogen-stub
  base version.
* Remove a whole slew of machinery to support JavaScript-style
  code stub generation, since it ultimately proved unwieldy,
  brittle and baroque. This cleanup includes removing the shared
  code stub context, several example stubs and a tangle of build
  file changes.

BUG=
==========

to

==========
[stubs] A new approach to TF stubs

* Add a sibling interface to InterpreterAssembler called
  CodeStubAssembler which provides a wrapper around the
  RawMachineAssembler and is intented to make it easy to build
  efficient cross-platform code stubs. Much of the implementation
  of CodeStubAssembler is shamelessly stolen from the
  InterpreterAssembler, and the idea is to eventually merge the
  two interfaces somehow, probably moving the
  InterpreterAssembler interface over to use the
  CodeStubAssembler. Short-term, however, the two interfaces
  shall remain decoupled to increase our velocity developing the
  two systems in parallel.
* Implement the StringLength stub in TurboFan with the new
  CodeStubAssembler. Replace and remove the old Hydrogen-stub
  version.
* Remove a whole slew of machinery to support JavaScript-style
  code stub generation, since it ultimately proved unwieldy,
  brittle and baroque. This cleanup includes removing the shared
  code stub context, several example stubs and a tangle of build
  file changes.

BUG=
==========

[danno, 2015-12-02 07:20:29]

The CQ bit was checked by danno@chromium.org

[danno, 2015-12-02 07:20:29]

The patchset sent to the CQ was uploaded after l-g-t-m from
mstarzinger@chromium.org
Link to the patchset: https://codereview.chromium.org/1475953002/#ps220001
(title: "Fix build")

[commit-bot: I haz the power, 2015-12-02 07:20:44]

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

[commit-bot: I haz the power, 2015-12-02 07:23:22]

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

[commit-bot: I haz the power, 2015-12-02 07:23:23]

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

[danno, 2015-12-02 07:36:41]

danno@chromium.org changed reviewers:
+ yangguo@chromium.org

[danno, 2015-12-02 07:37:00]

Yang, could you please take a look at the serializer changes?

[Yang, 2015-12-02 11:57:32]

On 2015/12/02 07:37:00, danno wrote:
> Yang, could you please take a look at the serializer changes?

src/snapshot lgtm.

[danno, 2015-12-02 12:18:49]

Description was changed from

==========
[stubs] A new approach to TF stubs

* Add a sibling interface to InterpreterAssembler called
  CodeStubAssembler which provides a wrapper around the
  RawMachineAssembler and is intented to make it easy to build
  efficient cross-platform code stubs. Much of the implementation
  of CodeStubAssembler is shamelessly stolen from the
  InterpreterAssembler, and the idea is to eventually merge the
  two interfaces somehow, probably moving the
  InterpreterAssembler interface over to use the
  CodeStubAssembler. Short-term, however, the two interfaces
  shall remain decoupled to increase our velocity developing the
  two systems in parallel.
* Implement the StringLength stub in TurboFan with the new
  CodeStubAssembler. Replace and remove the old Hydrogen-stub
  version.
* Remove a whole slew of machinery to support JavaScript-style
  code stub generation, since it ultimately proved unwieldy,
  brittle and baroque. This cleanup includes removing the shared
  code stub context, several example stubs and a tangle of build
  file changes.

BUG=
==========

to

==========
[stubs] A new approach to TF stubs

* Add a sibling interface to InterpreterAssembler called
  CodeStubAssembler which provides a wrapper around the
  RawMachineAssembler and is intented to make it easy to build
  efficient cross-platform code stubs. Much of the implementation
  of CodeStubAssembler is shamelessly stolen from the
  InterpreterAssembler, and the idea is to eventually merge the
  two interfaces somehow, probably moving the
  InterpreterAssembler interface over to use the
  CodeStubAssembler. Short-term, however, the two interfaces
  shall remain decoupled to increase our velocity developing the
  two systems in parallel.
* Implement the StringLength stub in TurboFan with the new
  CodeStubAssembler. Replace and remove the old Hydrogen-stub
  version.
* Remove a whole slew of machinery to support JavaScript-style
  code stub generation, since it ultimately proved unwieldy,
  brittle and baroque. This cleanup includes removing the shared
  code stub context, several example stubs and a tangle of build
  file changes.

BUG=v8:4587
LOG=n
==========

[danno, 2015-12-02 12:27:20]

The CQ bit was checked by danno@chromium.org

[danno, 2015-12-02 12:27:21]

The patchset sent to the CQ was uploaded after l-g-t-m from
mstarzinger@chromium.org
Link to the patchset: https://codereview.chromium.org/1475953002/#ps260001
(title: "Fix Win64 build")

[commit-bot: I haz the power, 2015-12-02 12:27:33]

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

[commit-bot: I haz the power, 2015-12-02 12:35:16]

Description was changed from

==========
[stubs] A new approach to TF stubs

* Add a sibling interface to InterpreterAssembler called
  CodeStubAssembler which provides a wrapper around the
  RawMachineAssembler and is intented to make it easy to build
  efficient cross-platform code stubs. Much of the implementation
  of CodeStubAssembler is shamelessly stolen from the
  InterpreterAssembler, and the idea is to eventually merge the
  two interfaces somehow, probably moving the
  InterpreterAssembler interface over to use the
  CodeStubAssembler. Short-term, however, the two interfaces
  shall remain decoupled to increase our velocity developing the
  two systems in parallel.
* Implement the StringLength stub in TurboFan with the new
  CodeStubAssembler. Replace and remove the old Hydrogen-stub
  version.
* Remove a whole slew of machinery to support JavaScript-style
  code stub generation, since it ultimately proved unwieldy,
  brittle and baroque. This cleanup includes removing the shared
  code stub context, several example stubs and a tangle of build
  file changes.

BUG=v8:4587
LOG=n
==========

to

==========
[stubs] A new approach to TF stubs

* Add a sibling interface to InterpreterAssembler called
  CodeStubAssembler which provides a wrapper around the
  RawMachineAssembler and is intented to make it easy to build
  efficient cross-platform code stubs. Much of the implementation
  of CodeStubAssembler is shamelessly stolen from the
  InterpreterAssembler, and the idea is to eventually merge the
  two interfaces somehow, probably moving the
  InterpreterAssembler interface over to use the
  CodeStubAssembler. Short-term, however, the two interfaces
  shall remain decoupled to increase our velocity developing the
  two systems in parallel.
* Implement the StringLength stub in TurboFan with the new
  CodeStubAssembler. Replace and remove the old Hydrogen-stub
  version.
* Remove a whole slew of machinery to support JavaScript-style
  code stub generation, since it ultimately proved unwieldy,
  brittle and baroque. This cleanup includes removing the shared
  code stub context, several example stubs and a tangle of build
  file changes.

BUG=v8:4587
LOG=n
==========

[commit-bot: I haz the power, 2015-12-02 12:35:17]

Committed patchset #14 (id:260001)

[commit-bot: I haz the power, 2015-12-02 12:35:29]

Description was changed from

==========
[stubs] A new approach to TF stubs

* Add a sibling interface to InterpreterAssembler called
  CodeStubAssembler which provides a wrapper around the
  RawMachineAssembler and is intented to make it easy to build
  efficient cross-platform code stubs. Much of the implementation
  of CodeStubAssembler is shamelessly stolen from the
  InterpreterAssembler, and the idea is to eventually merge the
  two interfaces somehow, probably moving the
  InterpreterAssembler interface over to use the
  CodeStubAssembler. Short-term, however, the two interfaces
  shall remain decoupled to increase our velocity developing the
  two systems in parallel.
* Implement the StringLength stub in TurboFan with the new
  CodeStubAssembler. Replace and remove the old Hydrogen-stub
  version.
* Remove a whole slew of machinery to support JavaScript-style
  code stub generation, since it ultimately proved unwieldy,
  brittle and baroque. This cleanup includes removing the shared
  code stub context, several example stubs and a tangle of build
  file changes.

BUG=v8:4587
LOG=n
==========

to

==========
[stubs] A new approach to TF stubs

* Add a sibling interface to InterpreterAssembler called
  CodeStubAssembler which provides a wrapper around the
  RawMachineAssembler and is intented to make it easy to build
  efficient cross-platform code stubs. Much of the implementation
  of CodeStubAssembler is shamelessly stolen from the
  InterpreterAssembler, and the idea is to eventually merge the
  two interfaces somehow, probably moving the
  InterpreterAssembler interface over to use the
  CodeStubAssembler. Short-term, however, the two interfaces
  shall remain decoupled to increase our velocity developing the
  two systems in parallel.
* Implement the StringLength stub in TurboFan with the new
  CodeStubAssembler. Replace and remove the old Hydrogen-stub
  version.
* Remove a whole slew of machinery to support JavaScript-style
  code stub generation, since it ultimately proved unwieldy,
  brittle and baroque. This cleanup includes removing the shared
  code stub context, several example stubs and a tangle of build
  file changes.

BUG=v8:4587
LOG=n

Committed: https://crrev.com/3e7e3ed726dd016dc6ae89803999a28fba2362c7
Cr-Commit-Position: refs/heads/master@{#32508}
==========

[commit-bot: I haz the power, 2015-12-02 12:35:30]

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