commit 403646caafc33528b916d0b1c5a48367a351d63f
author sbarati@apple.com <sbarati@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc> Thu Nov 22 03:43:30 2018 +0000
committer sbarati@apple.com <sbarati@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc> Thu Nov 22 03:43:30 2018 +0000
tree bc5c88ab35e51b8d1ba840ff1415c6d6bf30530f
parent 735e5ef65ad434695c74081f76abe881cb310788

DFGSpeculativeJIT should not &= exitOK with mayExit(node)
https://bugs.webkit.org/show_bug.cgi?id=191897
<rdar://problem/45871998>

Reviewed by Mark Lam.

JSTests:

* stress/exitok-is-not-the-same-as-mayExit.js: Added.
(bar):
(foo):

Source/JavaScriptCore:

exitOK is a statement about it being legal to exit. mayExit() is about being
conservative and returning false only if an OSR exit *could never* happen.
mayExit() tries to be as smart as possible to see if it can return false.
It can't return false if a runtime exit *could* happen. However, there is
code in the compiler where mayExit() returns false (because it uses data
generated from AI about type checks being proved), but the code we emit in the
compiler backend unconditionally generates an OSR exit, even if that exit may
never execute. For example, let's say we have this IR:

SomeNode(Boolean:@input)

And we always emit code like this as a way of emitting a boolean type check:

jump L1 if input == true
jump L1 if input == false
emit an OSR exit

In such a program, when we generate the above OSR exit, in a validationEnabled()
build, and if @input is proved to be a boolean, we'll end up crashing because we
have the bogus assertion saying !exitOK. This is one reason why things are cleaner
if we don't conflate mayExit() with exitOK.

* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileCurrentBlock):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@238437 268f45cc-cd09-0410-ab3c-d52691b4dbfc