Otherwise OSR exit may decided to set them to Undefined.
Currently a variable may appear to be dead at a basic block boundary even though it is captured. As a hack, we can peek at the first node of the successor block(s) and check what variables are captured at that node's code origin. But that's just disgusting and wrong. The right solution is to change how captured variables are flushed. Currently we flush SetLocals by planting a Flush node right after them: a: SetLocal(thingy) b: Flush(@a) But we could instead have a flush right before each SetLocal: a: Flush(...) b: SetLocal(thingy) As well as a Flush for all captured variables at the return site. That will effectively keep variables alive through the whole span of code in which they are captured.
Created attachment 144458 [details] work in progress
Created attachment 144464 [details] it's starting to work
Created attachment 144616 [details] more Still making sure that I've dotted all of my t's.
Created attachment 144629 [details] even more It's starting to pass tests.
Created attachment 144638 [details] the patch
Landed in http://trac.webkit.org/changeset/118858
Just for your information, I've got a build warning on my laptop as below. :-) [ 5%] Building CXX object Source/JavaScriptCore/CMakeFiles/javascriptcore_efl.dir/dfg/DFGCapabilities.cpp.o /home/kangilhan/dev/WebKit/Source/JavaScriptCore/dfg/DFGByteCodeParser.cpp: In member function ‘JSC::DFG::ArgumentPosition* JSC::DFG::ByteCodeParser::findArgumentPositionForLocal(int)’: /home/kangilhan/dev/WebKit/Source/JavaScriptCore/dfg/DFGByteCodeParser.cpp:361:73: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]