SSI implementation.

src/hydrogen-instructions.cc

Index: src/hydrogen-instructions.cc
diff --git a/src/hydrogen-instructions.cc b/src/hydrogen-instructions.cc
index a05fa204252993b1b29b51c11747120f76845146..61ca9729f34a9b1357a79bc20ba82f6652c16978 100644
--- a/src/hydrogen-instructions.cc
+++ b/src/hydrogen-instructions.cc
@@ -760,6 +760,23 @@ void HBoundsCheck::PrintDataTo(StringStream* stream) {
 }
 
 
+void HBoundsCheck::BuildSsi() {
+  HInstruction* current = this;
+
+  current = HSsiDefinition::New(
+      length(), current, HSsiDefinition::IF_TAGGED_IS_SMI, length());

[danno, 2012/12/28 10:42:41]

I don't think we want to handle "SMI-ness" here with SSI here yet. We currently
track SMI-ness using the HType of a HValue, and I don't think it makes sense to
add a new mechanism to do so.  At the very least, SSI nodes that have SMIs
values should return HType::Smi(). 

+
+  current = HSsiDefinition::New(
+      index(), current, HSsiDefinition::IF_TAGGED_IS_SMI, index());
+  current = HSsiDefinition::New(
+      current, current, HSsiDefinition::GE,
+      block()->graph()->GetConstant0());
+  HSsiDefinition::New(
+      current, current, HSsiDefinition::LT,
+      length());
+}
+
+
 void HCallConstantFunction::PrintDataTo(StringStream* stream) {
   if (IsApplyFunction()) {
     stream->Add("optimized apply ");
@@ -2237,6 +2254,62 @@ HType HValue::CalculateInferredType() {
 }
 
 
+HSsiDefinition* HSsiDefinition::New(HValue* previous_definition,
+                                    HInstruction* insertion_point,
+                                    ValueInfoRelation relation,
+                                    HValue* constraint,
+                                    int delta) {
+  return new (previous_definition->block()->zone()) HSsiDefinition(
+      previous_definition, insertion_point, relation, constraint, delta);
+}
+
+
+HSsiDefinition::HSsiDefinition(HValue* previous_definition,
+                               HInstruction* insertion_point,
+                               ValueInfoRelation relation,

[danno, 2012/12/28 10:42:41]

I think I would pre just a bit more abstraction here. I think what you want is a
SSIInformation type that abstracts the type of information you can annotate a
value with. You already have two different ones, so I think it makes sense, i.e.
one for comparison relation and one for a type change (i.e. ensuring the
"SMIness" of a value).

+                               HValue* constraint,
+                               int delta)
+    : HUnaryOperation(previous_definition),
+      value_before_ssi_(previous_definition->ValueBeforeSsi()),
+      relation_(relation),
+      constraint_(constraint),
+      delta_(delta) {
+  set_representation(value_before_ssi_->representation());
+  InsertAfter(insertion_point);
+
+  // Set the flag so while adjusting uses "this" will appear not to be
+  // dominated by itself: previous_definition_ in "this" must not be changed.
+  SetFlag(kProcessedBySsi);
+
+  HUseIterator uses = previous_definition->uses();
+  while (!uses.Done()) {
+    HValue* use = uses.value();
+    int index = uses.index();
+    uses.Advance();
+
+    // We need to update all dominated uses.
+    // If the use is in the same block as the definition we check if is has
+    // already been processed by SSI or if it is a phi: if not it is dominated.
+    if ((block() == use->block() && !
+        (use->CheckFlag(kProcessedBySsi) || use->IsPhi())) ||
+        block()->Dominates(use->block())) {
+      use->SetOperandAt(index, this);
+    }
+  }
+}
+
+
+void HSsiDefinition::PrintDataTo(StringStream* stream) {
+  stream->Add("(previous: ");
+  previous_definition()->PrintNameTo(stream);
+  stream->Add(", relation: ");
+  ValueBeforeSsi()->PrintNameTo(stream);
+  stream->Add(" %s ", RelationName(relation_));
+  constraint()->PrintNameTo(stream);
+  stream->Add(")");
+}
+
+
 HType HCheckMaps::CalculateInferredType() {
   return value()->type();
 }