Record the HashSet/HashMap operations in DFG/FTL/B3 and replay them in a benchmark

[WebKit-https.git] / Source / JavaScriptCore / dfg / DFGCombinedLiveness.h

diff --git a/Source/JavaScriptCore/dfg/DFGCombinedLiveness.h b/Source/JavaScriptCore/dfg/DFGCombinedLiveness.h
index ff761cf..e1ac76d 100644 (file)
--- a/Source/JavaScriptCore/dfg/DFGCombinedLiveness.h
+++ b/Source/JavaScriptCore/dfg/DFGCombinedLiveness.h
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2015 Apple Inc. All rights reserved.
+ * Copyright (C) 2015-2016 Apple Inc. All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
@@ -23,8 +23,7 @@
  * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 
  */
 
-#ifndef DFGCombinedLiveness_h
-#define DFGCombinedLiveness_h
+#pragma once
 
 #if ENABLE(DFG_JIT)
 
@@ -34,20 +33,22 @@
 namespace JSC { namespace DFG {
 
 // Returns the set of nodes live at tail, both due to due DFG and due to bytecode (i.e. OSR exit).
-HashSet<Node*> liveNodesAtHead(Graph&, BasicBlock*);
+NodeSet liveNodesAtHead(Graph&, BasicBlock*);
 
+// WARNING: This currently does not reason about the liveness of shadow values. The execution
+// semantics of DFG SSA are that an Upsilon stores to the shadow value of a Phi, and the Phi loads
+// from that shadow value. Hence, the shadow values are like variables, and have liveness. The normal
+// liveness analysis will tell you about the liveness of shadow values. It's OK to ignore shadow
+// values if you treat Upsilon as an opaque escape, and all of the clients of CombinedLiveness do so.
 struct CombinedLiveness {
     CombinedLiveness() { }
     
     CombinedLiveness(Graph&);
     
-    BlockMap<HashSet<Node*>> liveAtHead;
-    BlockMap<HashSet<Node*>> liveAtTail;
+    BlockMap<NodeSet> liveAtHead;
+    BlockMap<NodeSet> liveAtTail;
 };
 
 } } // namespace JSC::DFG
 
 #endif // ENABLE(DFG_JIT)
-
-#endif // DFGCombinedLiveness_h
-