Insert dummy conversion instruction for impossible conversion requests.

runtime/vm/flow_graph_optimizer.cc

Index: runtime/vm/flow_graph_optimizer.cc
diff --git a/runtime/vm/flow_graph_optimizer.cc b/runtime/vm/flow_graph_optimizer.cc
index 6c3cb7bcc028d817e5b4d4e46d0d717671f765ca..74137bc45cb231e1e1ac8a394f204caf3d352e78 100644
--- a/runtime/vm/flow_graph_optimizer.cc
+++ b/runtime/vm/flow_graph_optimizer.cc
@@ -397,6 +397,22 @@ void FlowGraphOptimizer::InsertConversion(Representation from,
     converted = new UnboxUint32x4Instr(use->CopyWithType(), deopt_id);
   } else if ((from == kUnboxedUint32x4) && (to == kTagged)) {
     converted = new BoxUint32x4Instr(use->CopyWithType());
+  } else {
+    const intptr_t deopt_id = (deopt_target != NULL) ?
+        deopt_target->DeoptimizationTarget() : Isolate::kNoDeoptId;
+    // We have failed to find a suitable conversion instruction.
+    // Insert a "dummy" conversion instruction with the correct
+    // "to" representation. The inserted instruction will trigger a
+    // a deoptimization if executed. See issue #12417 for a discussion.
+    if (to == kUnboxedDouble) {
+      converted = new UnboxDoubleInstr(use->CopyWithType(), deopt_id);

[Florian Schneider, 2013/08/15 09:11:35]

How about inserting a Box- and an Unbox-instruction to avoid deoptimization here
and in the other cases?

[srdjan, 2013/08/15 14:34:39]

What John has observed is that this code is actually never executed. It occurs
when inlining a function. The argument types are known and match one control
flow, but other (never possible) control flows are not eliminated and legal code
must still be generated for them as well (control flows are formed by is-a test
on arguments). John may provide more information.

[Cutch, 2013/08/15 14:35:02]

We are being asked to convert an UnboxedFloat32x4 to an UnboxedDouble. Even if
we inserted a BoxFloat32x4Instr followed by an UnboxDoubleInstr a deoptimization
will be triggered.

[Florian Schneider, 2013/08/16 10:31:18]

Still, I don't understand how this should work: Even if never executed, the
representations still should match: Unbox-instructions need a boxed input
(tagged) which comes in a regular register. An unboxed float32x4 value comes in
a XMM register.

[Cutch, 2013/08/16 15:57:05]

So what ends up happening is that unboxed -> tagged conversion routine is
inserted anyways. I'm sending you a CL which makes this explicit and fixes the
issue you found below.

+    } else if (to == kUnboxedUint32x4) {
+      converted = new UnboxDoubleInstr(use->CopyWithType(), deopt_id);

[Florian Schneider, 2013/08/16 10:31:18]

Ok, but shouldn't this be UnboxUint32x4Instr here?

[Cutch, 2013/08/16 15:57:05]

Yes.

+    } else if (to == kUnboxedFloat32x4) {
+      converted = new UnboxDoubleInstr(use->CopyWithType(), deopt_id);

[Florian Schneider, 2013/08/16 10:31:18]

Likewise, UnboxFloat32x4Instr here?

+    } else if (to == kUnboxedMint) {
+      converted = new UnboxIntegerInstr(use->CopyWithType(), deopt_id);
+    }
   }
   ASSERT(converted != NULL);
   use->BindTo(converted);