``` bool validate(JSValue value) const { if (isHeapTop()) return true; ``` However, JSValue() is not part of heap top, but would return true if asked to validate on an AbstractValue that isHeapTop().
(In reply to Saam Barati from comment #0) > ``` > bool validate(JSValue value) const > { > if (isHeapTop()) > return true; > ``` > > However, JSValue() is not part of heap top, but would return true if asked > to validate on an AbstractValue that isHeapTop(). JSValue() in AbstractValue means that the value is “any JSValue”. There is no way to reflect folding to JSValue() in abstract value.
(In reply to Filip Pizlo from comment #1) > (In reply to Saam Barati from comment #0) > > ``` > > bool validate(JSValue value) const > > { > > if (isHeapTop()) > > return true; > > ``` > > > > However, JSValue() is not part of heap top, but would return true if asked > > to validate on an AbstractValue that isHeapTop(). > > JSValue() in AbstractValue means that the value is “any JSValue”. There is > no way to reflect folding to JSValue() in abstract value. The scenario I'm worried about is OSR entry. Let's say that this AbstractValue has type SpecHeapTop (and top for all the other things too). Let's say we deleted a CheckTDZ because we saw the type is SpecHeapTop. Let's also say that we're now OSR entering with the TDZ value (JSValue()). I think that would lead to a bug.
(In reply to Saam Barati from comment #2) > (In reply to Filip Pizlo from comment #1) > > (In reply to Saam Barati from comment #0) > > > ``` > > > bool validate(JSValue value) const > > > { > > > if (isHeapTop()) > > > return true; > > > ``` > > > > > > However, JSValue() is not part of heap top, but would return true if asked > > > to validate on an AbstractValue that isHeapTop(). > > > > JSValue() in AbstractValue means that the value is “any JSValue”. There is > > no way to reflect folding to JSValue() in abstract value. > > The scenario I'm worried about is OSR entry. > > Let's say that this AbstractValue has type SpecHeapTop (and top for all the > other things too). Let's say we deleted a CheckTDZ because we saw the type > is SpecHeapTop. Let's also say that we're now OSR entering with the TDZ > value (JSValue()). I think that would lead to a bug. I'm not saying that it wouldn't. I'm just saying that AbstractValue::m_value being JSValue() means "top JSValue". So if AbstractValue::m_value is empty, it doesn't mean JSValue().
Created attachment 365426 [details] WIP Currently crashing in a lot of tests. I need to figure out why.
Created attachment 365437 [details] patch
Attachment 365437 [details] did not pass style-queue: ERROR: Source/JavaScriptCore/dfg/DFGStructureAbstractValue.h:235: The parameter name "structure" adds no information, so it should be removed. [readability/parameter_name] [5] ERROR: Source/JavaScriptCore/dfg/testdfg.cpp:30: Alphabetical sorting problem. [build/include_order] [4] Total errors found: 2 in 11 files If any of these errors are false positives, please file a bug against check-webkit-style.
Created attachment 365439 [details] patch
Attachment 365439 [details] did not pass style-queue: ERROR: Source/JavaScriptCore/dfg/DFGStructureAbstractValue.h:235: The parameter name "structure" adds no information, so it should be removed. [readability/parameter_name] [5] ERROR: Source/JavaScriptCore/dfg/testdfg.cpp:30: Alphabetical sorting problem. [build/include_order] [4] Total errors found: 2 in 11 files If any of these errors are false positives, please file a bug against check-webkit-style.
Comment on attachment 365439 [details] patch r=me too.
Comment on attachment 365439 [details] patch Clearing flags on attachment: 365439 Committed r243278: <https://trac.webkit.org/changeset/243278>
All reviewed patches have been landed. Closing bug.
<rdar://problem/49095372>