Title: [183763] trunk/Source/_javascript_Core
- Revision
- 183763
- Author
- [email protected]
- Date
- 2015-05-04 13:11:58 -0700 (Mon, 04 May 2015)
Log Message
Allocation sinking is prohibiting the creation of phis between a Phantom object and its materialization
https://bugs.webkit.org/show_bug.cgi?id=144587
Rubber stamped by Filip Pizlo.
When sinking object allocations, we ensure in
determineMaterializationPoints that whenever an allocation is
materialized on a path to a block, it is materialized in all such
paths. Thus when running the SSA calculator to place Phis in
placeMaterializationPoints, we can't encounter a situation where some
Upsilons are referring to a materialization while others are referring
to the phantom object.
This replaces the code that was adding a materialization late in
placeMaterializationPoints to handle that case by an assertion that it
does not happen, which will make
https://bugs.webkit.org/show_bug.cgi?id=143073 easier to implement.
* dfg/DFGObjectAllocationSinkingPhase.cpp:
(JSC::DFG::ObjectAllocationSinkingPhase::placeMaterializationPoints):
Modified Paths
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (183762 => 183763)
--- trunk/Source/_javascript_Core/ChangeLog 2015-05-04 19:33:38 UTC (rev 183762)
+++ trunk/Source/_javascript_Core/ChangeLog 2015-05-04 20:11:58 UTC (rev 183763)
@@ -1,3 +1,26 @@
+2015-05-04 Basile Clement <[email protected]>
+
+ Allocation sinking is prohibiting the creation of phis between a Phantom object and its materialization
+ https://bugs.webkit.org/show_bug.cgi?id=144587
+
+ Rubber stamped by Filip Pizlo.
+
+ When sinking object allocations, we ensure in
+ determineMaterializationPoints that whenever an allocation is
+ materialized on a path to a block, it is materialized in all such
+ paths. Thus when running the SSA calculator to place Phis in
+ placeMaterializationPoints, we can't encounter a situation where some
+ Upsilons are referring to a materialization while others are referring
+ to the phantom object.
+
+ This replaces the code that was adding a materialization late in
+ placeMaterializationPoints to handle that case by an assertion that it
+ does not happen, which will make
+ https://bugs.webkit.org/show_bug.cgi?id=143073 easier to implement.
+
+ * dfg/DFGObjectAllocationSinkingPhase.cpp:
+ (JSC::DFG::ObjectAllocationSinkingPhase::placeMaterializationPoints):
+
2015-05-04 Ryosuke Niwa <[email protected]>
Extending undefined in class syntax should throw a TypeError
Modified: trunk/Source/_javascript_Core/dfg/DFGObjectAllocationSinkingPhase.cpp (183762 => 183763)
--- trunk/Source/_javascript_Core/dfg/DFGObjectAllocationSinkingPhase.cpp 2015-05-04 19:33:38 UTC (rev 183762)
+++ trunk/Source/_javascript_Core/dfg/DFGObjectAllocationSinkingPhase.cpp 2015-05-04 20:11:58 UTC (rev 183763)
@@ -471,19 +471,8 @@
SSACalculator::Variable* variable = phiDef->variable();
Node* allocation = indexToNode[variable->index()];
- Node* originalIncoming = mapping.get(allocation);
- Node* incoming;
- if (originalIncoming == allocation) {
- // If we have a Phi that combines materializations with the original
- // phantom object, then the path with the phantom object must materialize.
-
- incoming = createMaterialize(allocation, upsilonWhere);
- m_insertionSet.insert(upsilonInsertionPoint, incoming);
- insertOSRHintsForUpdate(
- m_insertionSet, upsilonInsertionPoint, upsilonOrigin,
- availabilityCalculator.m_availability, originalIncoming, incoming);
- } else
- incoming = originalIncoming;
+ Node* incoming = mapping.get(allocation);
+ DFG_ASSERT(m_graph, incoming, incoming != allocation);
m_insertionSet.insertNode(
upsilonInsertionPoint, SpecNone, Upsilon, upsilonOrigin,
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
