Remove an invalid assertion in DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareN...
authormark.lam@apple.com <mark.lam@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Thu, 21 Mar 2019 23:34:31 +0000 (23:34 +0000)
committermark.lam@apple.com <mark.lam@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Thu, 21 Mar 2019 23:34:31 +0000 (23:34 +0000)
commit08e4a4dc3206c29a16753e624e1e2d498332b1f2
tree73846affeb4b3fa6ec543103f58f0ba8db066034
parent9719ae59b4b5e562cc3bf1fbedfcb8a1d7d4bef1
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):

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@243344 268f45cc-cd09-0410-ab3c-d52691b4dbfc
JSTests/ChangeLog
JSTests/stress/dfg-compare-eq-via-nonSpeculativeNonPeepholeCompareNullOrUndefined.js [new file with mode: 0644]
Source/JavaScriptCore/ChangeLog
Source/JavaScriptCore/dfg/DFGSpeculativeJIT64.cpp