Consider that you have code like: a: ... b: MovHint(@a) c: ValueRep(@a) d: SetLocal(@c) ... e: Flush(@d) If the code between @d and @e doesn't observe the flushed value, we current convert this to: a: ... b: MovHint(@a) c: ValueRep(@a) d: SetLocal(@c) ... e: Phantom(@c) That's wrong, because @c is not MovHinted to anything. This causes @a to die and if we exit, we won't have a value for this local. Our IR supports the notion that two logically equivalent but not identical values may be used for the MovHint and SetLocal. Phantoms should use the values that MovHints used. So, when strength-reducing a Flush or PhantomLocal to a Phantom we need to put the Phantom on the value that would have gotten MovHinted into that local.
This issue was revealed by the new inlining opportunities introduced by https://bugs.webkit.org/show_bug.cgi?id=140660.
Created attachment 245765 [details] the patch
Comment on attachment 245765 [details] the patch View in context: https://bugs.webkit.org/attachment.cgi?id=245765&action=review r=me > Source/JavaScriptCore/dfg/DFGCPSRethreadingPhase.cpp:267 > + // be keeping the last MovHinted value of that local alive. Would it be better to say "keep" instead of "be keeping"?
Comment on attachment 245765 [details] the patch View in context: https://bugs.webkit.org/attachment.cgi?id=245765&action=review >> Source/JavaScriptCore/dfg/DFGCPSRethreadingPhase.cpp:267 >> + // be keeping the last MovHinted value of that local alive. > > Would it be better to say "keep" instead of "be keeping"? Good point, will make that change!
Landed in http://trac.webkit.org/changeset/179477