[turbofan] Optimized support for CreateGeneratorObject.

src/compiler/js-operator.cc

Index: src/compiler/js-operator.cc
diff --git a/src/compiler/js-operator.cc b/src/compiler/js-operator.cc
index 1e2c15882b2f52a471574e460bb2b91b1e60027b..dbd889a86286d56a9d23b1b75733a0a0b88b30e8 100644
--- a/src/compiler/js-operator.cc
+++ b/src/compiler/js-operator.cc
@@ -904,6 +904,12 @@ const Operator* JSOperatorBuilder::DeleteProperty() {
       3, 1, 1, 1, 1, 2);                                     // counts
 }
 
+const Operator* JSOperatorBuilder::CreateGeneratorObject() {
+  return new (zone()) Operator(                                     // --
+      IrOpcode::kJSCreateGeneratorObject, Operator::kEliminatable,  // opcode
+      "JSCreateGeneratorObject",                                    // name
+      2, 1, 0, 1, 1, 0);                                            // counts

[Benedikt Meurer, 2017/05/06 11:50:09]

this should have a control input as well.

[mvstanton, 2017/05/06 17:52:30]

Hmm, I chatted with Michi rather extensively about that, but I guess we focused
on the point that a control *output* isn't necessary. I noticed other
eliminatable opcodes that had neither control in nor out. Can you explain why I
need the control in? (to a newb :p)

[Benedikt Meurer, 2017/05/06 21:29:23]

This way the allocation cannot get hoisted above an IfTrue/IfFalse.

[mvstanton, 2017/05/06 22:25:31]

Good point. We were thinking about the fact that first other objects are
allocated (a context and various things), and through the wiring into the effect
chain our allocation should end up in the right place. Let's chat about it
Monday...

+}
 
 const Operator* JSOperatorBuilder::LoadGlobal(const Handle<Name>& name,
                                               const VectorSlotPair& feedback,