Validate that all instructions dominate their inputs. And fix a bug where that did not happen.

lib/compiler/implementation/ssa/validate.dart

Index: lib/compiler/implementation/ssa/validate.dart
===================================================================
--- lib/compiler/implementation/ssa/validate.dart	(revision 8084)
+++ lib/compiler/implementation/ssa/validate.dart	(working copy)
@@ -82,6 +82,28 @@
 
     if (!isValid) return;
     block.forEachPhi(visitInstruction);
+
+    // Make sure the parameters of a phi are dominating the
+    // corresponding predecessor block.

[Lasse Reichstein Nielsen, 2012/05/30 09:35:14]

We usually use "dominating" about blocks, not instructions.
Maybe say that the parameters/inputs' blocks dominate the corresponding
predecessor blocks (with a comment that blocks dominate themselves).

[ngeoffray, 2012/05/30 10:19:07]

Done.

+    block.forEachPhi((HPhi phi) {
+      for (int i = 0; i < phi.inputs.length; i++) {
+        HInstruction input = phi.inputs[i];
+        if (!input.block.dominates(block.predecessors[i])) {
+          markInvalid("Definition does not dominate use");
+        }
+      }
+    });
+
+    // Make sure the inputs of an instruction dominate the
+    // instruction.
+    block.forEachInstruction((HInstruction instruction) {
+      for (HInstruction input in instruction.inputs) {

[Lasse Reichstein Nielsen, 2012/05/30 09:35:14]

This is an un-pretty combination of functional for-each and iterator based
for-each. How about making blocks/instruction-lists Iterable<HInstruction>
instead?
Then you can do
 for (HPhi phi in block.phis)
and
 for (HInstruction instruction in block)

[ngeoffray, 2012/05/30 10:19:07]

As discussed, it doesn't look un-pretty to me, as I usually use forEach on
non-array data structures, and forin (or for (int i....)) on arrays.

+        if (!input.block.dominates(block)) {
+          markInvalid("Definition does not dominate use");
+        }
+      }
+    });
+
     super.visitBasicBlock(block);
   }