Subzero: Rewrite the pass timing infrastructure.

src/IceOperand.cpp

Index: src/IceOperand.cpp
diff --git a/src/IceOperand.cpp b/src/IceOperand.cpp
index d1854f4f0f0a6d4e48306b87acef22f227f2b84b..00539210997aa5e239869b21b9096e89a1bd118b 100644
--- a/src/IceOperand.cpp
+++ b/src/IceOperand.cpp
@@ -122,9 +122,19 @@ bool LiveRange::overlaps(const LiveRange &Other) const {
 }
 
 bool LiveRange::overlaps(InstNumberT OtherBegin) const {
+  for (RangeType::const_iterator I = Range.begin(), E = Range.end(); I != E;
+       ++I) {
+    if (OtherBegin >= I->second)

[jvoung (off chromium), 2014/09/30 23:38:44]

So the issue was that the ranges are sorted the other way?

OtherBegin might be >= I->second for some of the earlier ranges, even though it
overlaps later?

[Jim Stichnoth, 2014/09/30 23:49:16]

No, the segments of the live range must be sorted, though that is only enforced
if the USE_SET define is enabled.  E.g., LiveRange::overlaps() relies on
iterating in increasing sorted order.

The only thing that makes sense to me is that I implemented something, validated
it against the original implementation, cleaned out the validation code, then
"optimized" the new implementation without re-validating. :(

+      return false;
+    if (I->first <= OtherBegin)
+      return true;
+  }
+  return false;
+#if 0 // An equivalent but less inefficient implementation:
   LiveRange Temp;
   Temp.addSegment(OtherBegin, OtherBegin + 1);
   return overlaps(Temp);
+#endif
 }
 
 // Returns true if the live range contains the given instruction
@@ -259,6 +269,8 @@ const Inst *VariableTracking::getSingleDefinition() const {
 }
 
 void VariablesMetadata::init() {
+  static TimerIdT IDvmetadata = GlobalContext::getTimerID("vmetadata");
+  TimerMarker T(IDvmetadata, Func->getContext());
   Metadata.clear();
   Metadata.resize(Func->getNumVariables());