Collect type profile for DevTools.

src/compiler/bytecode-graph-builder.cc

 // Copyright 2015 the V8 project authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "src/compiler/bytecode-graph-builder.h"
 
 #include "src/ast/ast.h"
 #include "src/ast/scopes.h"
 #include "src/compilation-info.h"
 #include "src/compiler/compiler-source-position-table.h"
@@ skipping 784 matching lines @@
   Node* value = environment()->LookupAccumulator();
   int flags = bytecode_iterator().GetFlagOperand(2);
   VectorSlotPair feedback =
       CreateVectorSlotPair(bytecode_iterator().GetIndexOperand(3));
 
   const Operator* op = javascript()->StoreDataPropertyInLiteral(feedback);
   Node* node = NewNode(op, object, name, value, jsgraph()->Constant(flags));
   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),
       bytecode_iterator().GetIndexOperand(1), false);
   Node* node = NewNode(op);
   Node* context =
       environment()->LookupRegister(bytecode_iterator().GetRegisterOperand(0));
   NodeProperties::ReplaceContextInput(node, context);
   environment()->BindAccumulator(node);
 }
@@ skipping 1615 matching lines @@
         it->source_position().ScriptOffset(), start_position_.InliningId()));
     it->Advance();
   } else {
     DCHECK_GT(it->code_offset(), offset);
   }
 }
 
 }  // namespace compiler
 }  // namespace internal
 }  // namespace v8