Collect type profile for DevTools.

src/compiler/bytecode-graph-builder.cc

Index: src/compiler/bytecode-graph-builder.cc
diff --git a/src/compiler/bytecode-graph-builder.cc b/src/compiler/bytecode-graph-builder.cc
index 10ded107ed718071dc64b51a60b1cdbd1a378da5..0f496ddc0f2bdc94fab7223e5bc516beb3c3d487 100644
--- a/src/compiler/bytecode-graph-builder.cc
+++ b/src/compiler/bytecode-graph-builder.cc
@@ -802,6 +802,21 @@ void BytecodeGraphBuilder::VisitStaDataPropertyInLiteral() {
   environment()->RecordAfterState(node, Environment::kAttachFrameState);
 }
 
+void BytecodeGraphBuilder::VisitCollectTypeProfile() {
+  PrepareEagerCheckpoint();
+
+  Node* name =
+      environment()->LookupRegister(bytecode_iterator().GetRegisterOperand(0));
+  Node* value = environment()->LookupAccumulator();
+  VectorSlotPair feedback =
+      CreateVectorSlotPair(bytecode_iterator().GetIndexOperand(1));
+
+  const Operator* op = javascript()->CollectTypeProfile(feedback);

[rmcilroy, 2017/03/13 10:50:59]

Do we want to collect type profile data in optimized code as well as unoptimized
code? I don't think we update any other type feedback slots in TF code, and
having this in the graph for each assignment would probably cause TF not to be
able to do a bunch of optimizations.  Maybe we should just treat this as a noop
in TF?

[Franzi, 2017/03/13 12:01:56]

I think we want to collect types for optimized code as well (or is nothing
optimized once we're in debug mode?) 

[rmcilroy, 2017/03/13 12:05:45]

I thought generally nothing was optimized once we are in debug mode (certainly
things like breakpoints and such would no longer work as expected), but I may be
wrong about this - Yang any comment on this?

+
+  Node* node = NewNode(op, name, value);

[Michael Starzinger, 2017/03/14 13:12:43]

Do we ever want to optimize the CollectTypeProfile operator? Otherwise I would
vote for just using javascript()->CallRuntime(Runtime::kCollectTypeProfile)
directly here instead. Introducing a new opcode only makes sense if some reducer
actually handles it specifically.

[Yang, 2017/03/14 13:35:22]

We might want to optimize it in the future. But for now maybe we should keep it
simple.

[Michael Starzinger, 2017/03/14 13:41:38]

+1 to keeping it simple in the TurboFan IR for now until we have concrete plans.
Otherwise approach looks good.

[Franzi, 2017/03/14 15:55:11]

I deleted the opcode. Please have another look. Thanks!

+  environment()->RecordAfterState(node, Environment::kAttachFrameState);
+}
+
 void BytecodeGraphBuilder::VisitLdaContextSlot() {
   const Operator* op = javascript()->LoadContext(
       bytecode_iterator().GetUnsignedImmediateOperand(2),