Title: [121243] trunk/Source/_javascript_Core
Revision
121243
Author
fpi...@apple.com
Date
2012-06-26 02:22:45 -0700 (Tue, 26 Jun 2012)

Log Message

New fast/js/dfg-store-unexpected-value-into-argument-and-osr-exit.html fails on 32 bit
https://bugs.webkit.org/show_bug.cgi?id=89953

Reviewed by Zoltan Herczeg.

DFG 32-bit JIT was confused about the difference between a predicted type and a
proven type. This is easy to get confused about, since a local that is predicted int32
almost always means that the local must be an int32 since speculations are hoisted to
stores to locals. But that is less likely to be the case for arguments, where there is
an additional least-upper-bounding step: any store to an argument with a weird type
may force the argument to be any type.

This patch basically duplicates the functionality in DFGSpeculativeJIT64.cpp for
GetLocal: the decision of whether to load a local as an int32 (or as an array, or as
a boolean) is made based on the AbstractValue::m_type, which is a type proof, rather
than the VariableAccessData::prediction(), which is a predicted type.

* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):

Modified Paths

Diff

Modified: trunk/Source/_javascript_Core/ChangeLog (121242 => 121243)


--- trunk/Source/_javascript_Core/ChangeLog	2012-06-26 09:21:20 UTC (rev 121242)
+++ trunk/Source/_javascript_Core/ChangeLog	2012-06-26 09:22:45 UTC (rev 121243)
@@ -1,3 +1,25 @@
+2012-06-26  Filip Pizlo  <fpi...@apple.com>
+
+        New fast/js/dfg-store-unexpected-value-into-argument-and-osr-exit.html fails on 32 bit
+        https://bugs.webkit.org/show_bug.cgi?id=89953
+
+        Reviewed by Zoltan Herczeg.
+        
+        DFG 32-bit JIT was confused about the difference between a predicted type and a
+        proven type. This is easy to get confused about, since a local that is predicted int32
+        almost always means that the local must be an int32 since speculations are hoisted to
+        stores to locals. But that is less likely to be the case for arguments, where there is
+        an additional least-upper-bounding step: any store to an argument with a weird type
+        may force the argument to be any type.
+        
+        This patch basically duplicates the functionality in DFGSpeculativeJIT64.cpp for
+        GetLocal: the decision of whether to load a local as an int32 (or as an array, or as
+        a boolean) is made based on the AbstractValue::m_type, which is a type proof, rather
+        than the VariableAccessData::prediction(), which is a predicted type.
+
+        * dfg/DFGSpeculativeJIT32_64.cpp:
+        (JSC::DFG::SpeculativeJIT::compile):
+
 2012-06-25  Filip Pizlo  <fpi...@apple.com>
 
         JSC should try to make profiling deterministic because otherwise reproducing failures is

Modified: trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT32_64.cpp (121242 => 121243)


--- trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT32_64.cpp	2012-06-26 09:21:20 UTC (rev 121242)
+++ trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT32_64.cpp	2012-06-26 09:22:45 UTC (rev 121243)
@@ -1891,7 +1891,7 @@
                 break;
             }
         
-            if (isInt32Speculation(prediction)) {
+            if (isInt32Speculation(value.m_type)) {
                 GPRTemporary result(this);
                 m_jit.load32(JITCompiler::payloadFor(node.local()), result.gpr());
 
@@ -1903,7 +1903,7 @@
                 break;
             }
 
-            if (isArraySpeculation(prediction)) {
+            if (isArraySpeculation(value.m_type)) {
                 GPRTemporary result(this);
                 m_jit.load32(JITCompiler::payloadFor(node.local()), result.gpr());
 
@@ -1915,7 +1915,7 @@
                 break;
             }
 
-            if (isBooleanSpeculation(prediction)) {
+            if (isBooleanSpeculation(value.m_type)) {
                 GPRTemporary result(this);
                 m_jit.load32(JITCompiler::payloadFor(node.local()), result.gpr());
 
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-changes

Reply via email to