Changeset 243344 in webkit

Timestamp:

Mar 21, 2019, 4:34:31 PM (7 years ago)

Author:

mark.lam@apple.com

Message:

Remove an invalid assertion in DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNullOrUndefined().
​https://bugs.webkit.org/show_bug.cgi?id=196116
<rdar://problem/48976951>

Reviewed by Filip Pizlo.

JSTests:

• stress/dfg-compare-eq-via-nonSpeculativeNonPeepholeCompareNullOrUndefined.js: Added.

Source/JavaScriptCore:

The DFG backend should not make assumptions about what optimizations the front end
will or will not do. The assertion asserts that the operand cannot be known to be
a cell. However, it is not guaranteed that the front end will fold away this case.
Also, the DFG backend is perfectly capable of generating code to handle the case
where the operand is a cell.

The attached test case demonstrates a case where the operand can be a known cell.
The test needs to be run with the concurrent JIT and GC, and is racy. It used to
trip up this assertion about once every 10 runs or so.

• dfg/DFGSpeculativeJIT64.cpp:

(JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNullOrUndefined):

Location:

trunk

Files:

• JSTests/ChangeLog (modified) (1 diff)
• JSTests/stress/dfg-compare-eq-via-nonSpeculativeNonPeepholeCompareNullOrUndefined.js (added)
• Source/JavaScriptCore/ChangeLog (modified) (1 diff)
• Source/JavaScriptCore/dfg/DFGSpeculativeJIT64.cpp (modified) (1 diff)

trunk/JSTests/ChangeLog

@@ +1 @@
+2019-03-21  Mark Lam  <mark.lam@apple.com>
+
+        Remove an invalid assertion in DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNullOrUndefined().
+        https://bugs.webkit.org/show_bug.cgi?id=196116
+        <rdar://problem/48976951>
+
+        Reviewed by Filip Pizlo.
+
+        * stress/dfg-compare-eq-via-nonSpeculativeNonPeepholeCompareNullOrUndefined.js: Added.
+
 2019-03-21  Tadeu Zagallo  <tzagallo@apple.com>
 

trunk/Source/JavaScriptCore/ChangeLog

@@ +1 @@
+2019-03-21  Mark Lam  <mark.lam@apple.com>
+
+        Remove an invalid assertion in DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNullOrUndefined().
+        https://bugs.webkit.org/show_bug.cgi?id=196116
+        <rdar://problem/48976951>
+
+        Reviewed by Filip Pizlo.
+
+        The DFG backend should not make assumptions about what optimizations the front end
+        will or will not do.  The assertion asserts that the operand cannot be known to be
+        a cell.  However, it is not guaranteed that the front end will fold away this case.
+        Also, the DFG backend is perfectly capable of generating code to handle the case
+        where the operand is a cell.
+
+        The attached test case demonstrates a case where the operand can be a known cell.
+        The test needs to be run with the concurrent JIT and GC, and is racy.  It used to
+        trip up this assertion about once every 10 runs or so.
+
+        * dfg/DFGSpeculativeJIT64.cpp:
+        (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNullOrUndefined):
+
 2019-03-21  Tadeu Zagallo  <tzagallo@apple.com>
 

trunk/Source/JavaScriptCore/dfg/DFGSpeculativeJIT64.cpp

@@ -218 +218 @@
 void SpeculativeJIT::nonSpeculativeNonPeepholeCompareNullOrUndefined(Edge operand)
 {
-    ASSERT_WITH_MESSAGE(!masqueradesAsUndefinedWatchpointIsStillValid() || !isKnownCell(operand.node()), "The Compare should have been eliminated, it is known to be always false.");
-
     JSValueOperand arg(this, operand, ManualOperandSpeculation);
     GPRReg argGPR = arg.gpr();