Patch forthcoming.
Created attachment 217752 [details] work in progress
Created attachment 217753 [details] more things
Comment on attachment 217753 [details] more things View in context: https://bugs.webkit.org/attachment.cgi?id=217753&action=review > Source/JavaScriptCore/dfg/DFGByteCodeParser.cpp:3100 > + JSValue specificValue = > + watchpointSet ? watchpointSet->inferredValue() : JSValue(); > + if (!specificValue) { JSValue specificValue; if (watchpointSet) specificValue = watchPointSet->inferredValue(); (can inferredValue here ever be JSValue()?)
(In reply to comment #3) > (From update of attachment 217753 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=217753&action=review > > > Source/JavaScriptCore/dfg/DFGByteCodeParser.cpp:3100 > > + JSValue specificValue = > > + watchpointSet ? watchpointSet->inferredValue() : JSValue(); > > + if (!specificValue) { > > JSValue specificValue; > if (watchpointSet) > specificValue = watchPointSet->inferredValue(); (can inferredValue here ever be JSValue()?) That would be wrong, since watchpointSet->inferredValue() can be JSValue().
Actually, this whole approach is wrong. Consider this: function foo() { var WIDTH; function bar() { ... use WIDTH ... } WIDTH = 42; ... use bar } 1) Unless we do some static analysis we can't be sure that bar will be called after "WIDTH = 42". 2) op_enter is technically an assignment to WIDTH.
Created attachment 217755 [details] the wrong approach This is the wrong approach but I wanted to set aside the code anyway.
Actually, I think we totally want this. It'll work when combined with one-shot closure inference.
Created attachment 217861 [details] more
Created attachment 217883 [details] more
Created attachment 217889 [details] the patch
Created attachment 217912 [details] patch for landing
Landed in http://trac.webkit.org/changeset/159798