[Interpreter] Add support for Call bytecode to bytecode graph builder.

[Interpreter] Add support for Call bytecode to bytecode graph builder.

Adds support for visiting the Call bytecode to the bytecode graph builder.
This change also adds the call type feedback slot to the Call bytecode.
This is not currently used by the interpreter, but is used by the
graph builder.

Also adds a CallWide varient of the Call bytecode, and adds the kCount16
operand type.

BUG=v8:4280
LOG=N

[rmcilroy, 2015-11-11 16:31:23]

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

[commit-bot: I haz the power, 2015-11-11 16:31:32]

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

[commit-bot: I haz the power, 2015-11-11 16:32:27]

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

[commit-bot: I haz the power, 2015-11-11 16:32:28]

Dry run: Try jobs failed on following builders:
  v8_android_arm_compile_rel on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_android_arm_compile_rel/...)
  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/10641)
  v8_linux_gcc_compile_rel on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux_gcc_compile_rel/bu...)
  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_mipsel_compile_rel on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux_mipsel_compile_rel...)
  v8_mac_rel on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_mac_rel/builds/11737)
  v8_presubmit on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_presubmit/builds/7639)

[rmcilroy, 2015-11-11 16:33:22]

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

[rmcilroy, 2015-11-11 16:33:23]

This builds on Mythri's LoadIC CL https://codereview.chromium.org/1419373007/

Benedikt: Please take a look at compiler/
Orion / Mythri: Please take a look at interpreter/ and compiler/
Michi FYI (comments welcome).

[Benedikt Meurer, 2015-11-12 06:43:29]

LGTM on compiler.

[mythria, 2015-11-12 09:18:36]

lgtm

https://codereview.chromium.org/1437873002/diff/1/src/compiler/bytecode-graph...
File src/compiler/bytecode-graph-builder.cc (right):

https://codereview.chromium.org/1437873002/diff/1/src/compiler/bytecode-graph...
src/compiler/bytecode-graph-builder.cc:586: AddEmptyFrameStateInputs(value);
Just a note: I moved TODO to add real frame states from AddEmptyFrameStateInputs
to the place where it is called from (BuildNamedLoad and BuildBinaryOp). Since
the function says AddEmptyFrameState, I felt we should not have a TODO on the
function but have it from the place where it is called from. Now, I feel it is
better to add it to the function declaration to avoid having a TODO at every
place it is called from.

[rmcilroy, 2015-11-12 12:28:03]

https://codereview.chromium.org/1437873002/diff/1/src/compiler/bytecode-graph...
File src/compiler/bytecode-graph-builder.cc (right):

https://codereview.chromium.org/1437873002/diff/1/src/compiler/bytecode-graph...
src/compiler/bytecode-graph-builder.cc:586: AddEmptyFrameStateInputs(value);
On 2015/11/12 09:18:36, mythria wrote:
> Just a note: I moved TODO to add real frame states from
AddEmptyFrameStateInputs
> to the place where it is called from (BuildNamedLoad and BuildBinaryOp). Since
> the function says AddEmptyFrameState, I felt we should not have a TODO on the
> function but have it from the place where it is called from. Now, I feel it is
> better to add it to the function declaration to avoid having a TODO at every
> place it is called from. 

SGTM, done.

[oth, 2015-11-13 12:24:06]

lgtm.

https://codereview.chromium.org/1437873002/diff/40001/src/compiler/bytecode-g...
File src/compiler/bytecode-graph-builder.cc (right):

https://codereview.chromium.org/1437873002/diff/40001/src/compiler/bytecode-g...
src/compiler/bytecode-graph-builder.cc:575: // register has been loaded with
null / undefined explicitly or we are sure it
s/reciever/receiver/

https://codereview.chromium.org/1437873002/diff/40001/src/compiler/bytecode-g...
src/compiler/bytecode-graph-builder.cc:579: interpreter::Register reciever =
iterator.GetRegisterOperand(1);
s/reciever/receiver/

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

https://codereview.chromium.org/1437873002/diff/40001/src/interpreter/bytecod...
src/interpreter/bytecodes.h:127: /* TODO(rmcilroy): Wide register operands too?
*/                            \
I might remove this TODO as it's not clear this is unique to call. We need to
solve wide register operands in some sense but think we maybe able to solve this
with a fairly minimal change (translation layer in
BytecodeArrayBuilder::Output). Have a strawman to discuss / put in the design
doc. Also for constant pool entries.

[oth, 2015-11-17 09:55:55]

On 2015/11/13 12:24:06, oth wrote:
> lgtm.
> 
>
https://codereview.chromium.org/1437873002/diff/40001/src/compiler/bytecode-g...
> File src/compiler/bytecode-graph-builder.cc (right):
> 
>
https://codereview.chromium.org/1437873002/diff/40001/src/compiler/bytecode-g...
> src/compiler/bytecode-graph-builder.cc:575: // register has been loaded with
> null / undefined explicitly or we are sure it
> s/reciever/receiver/
> 
>
https://codereview.chromium.org/1437873002/diff/40001/src/compiler/bytecode-g...
> src/compiler/bytecode-graph-builder.cc:579: interpreter::Register reciever =
> iterator.GetRegisterOperand(1);
> s/reciever/receiver/
> 
>
https://codereview.chromium.org/1437873002/diff/40001/src/interpreter/bytecod...
> File src/interpreter/bytecodes.h (right):
> 
>
https://codereview.chromium.org/1437873002/diff/40001/src/interpreter/bytecod...
> src/interpreter/bytecodes.h:127: /* TODO(rmcilroy): Wide register operands
too?
> */                            \
> I might remove this TODO as it's not clear this is unique to call. We need to
> solve wide register operands in some sense but think we maybe able to solve
this
> with a fairly minimal change (translation layer in
> BytecodeArrayBuilder::Output). Have a strawman to discuss / put in the design
> doc. Also for constant pool entries.

Moving to a new CL to land on behalf of Ross:

https://codereview.chromium.org/1456453002

[oth, 2015-11-17 10:34:36]

Description was changed from

==========
[Interpreter] Add support for Call bytecode to bytecode graph builder.

Adds support for visiting the Call bytecode to the bytecode graph builder.
This change also adds the call type feedback slot to the Call bytecode.
This is not currently used by the interpreter, but is used by the
graph builder.

Also adds a CallWide varient of the Call bytecode, and adds the kCount16
operand type.

BUG=v8:4280
LOG=N
==========

to

==========
[Interpreter] Add support for Call bytecode to bytecode graph builder.

Adds support for visiting the Call bytecode to the bytecode graph builder.
This change also adds the call type feedback slot to the Call bytecode.
This is not currently used by the interpreter, but is used by the
graph builder.

Also adds a CallWide varient of the Call bytecode, and adds the kCount16
operand type.

BUG=v8:4280
LOG=N
==========