<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head><meta http-equiv="content-type" content="text/html; charset=utf-8" />
<title>[165700] trunk/Source/JavaScriptCore</title>
</head>
<body>
<style type="text/css"><!--
#msg dl.meta { border: 1px #006 solid; background: #369; padding: 6px; color: #fff; }
#msg dl.meta dt { float: left; width: 6em; font-weight: bold; }
#msg dt:after { content:':';}
#msg dl, #msg dt, #msg ul, #msg li, #header, #footer, #logmsg { font-family: verdana,arial,helvetica,sans-serif; font-size: 10pt; }
#msg dl a { font-weight: bold}
#msg dl a:link { color:#fc3; }
#msg dl a:active { color:#ff0; }
#msg dl a:visited { color:#cc6; }
h3 { font-family: verdana,arial,helvetica,sans-serif; font-size: 10pt; font-weight: bold; }
#msg pre { overflow: auto; background: #ffc; border: 1px #fa0 solid; padding: 6px; }
#logmsg { background: #ffc; border: 1px #fa0 solid; padding: 1em 1em 0 1em; }
#logmsg p, #logmsg pre, #logmsg blockquote { margin: 0 0 1em 0; }
#logmsg p, #logmsg li, #logmsg dt, #logmsg dd { line-height: 14pt; }
#logmsg h1, #logmsg h2, #logmsg h3, #logmsg h4, #logmsg h5, #logmsg h6 { margin: .5em 0; }
#logmsg h1:first-child, #logmsg h2:first-child, #logmsg h3:first-child, #logmsg h4:first-child, #logmsg h5:first-child, #logmsg h6:first-child { margin-top: 0; }
#logmsg ul, #logmsg ol { padding: 0; list-style-position: inside; margin: 0 0 0 1em; }
#logmsg ul { text-indent: -1em; padding-left: 1em; }#logmsg ol { text-indent: -1.5em; padding-left: 1.5em; }
#logmsg > ul, #logmsg > ol { margin: 0 0 1em 0; }
#logmsg pre { background: #eee; padding: 1em; }
#logmsg blockquote { border: 1px solid #fa0; border-left-width: 10px; padding: 1em 1em 0 1em; background: white;}
#logmsg dl { margin: 0; }
#logmsg dt { font-weight: bold; }
#logmsg dd { margin: 0; padding: 0 0 0.5em 0; }
#logmsg dd:before { content:'\00bb';}
#logmsg table { border-spacing: 0px; border-collapse: collapse; border-top: 4px solid #fa0; border-bottom: 1px solid #fa0; background: #fff; }
#logmsg table th { text-align: left; font-weight: normal; padding: 0.2em 0.5em; border-top: 1px dotted #fa0; }
#logmsg table td { text-align: right; border-top: 1px dotted #fa0; padding: 0.2em 0.5em; }
#logmsg table thead th { text-align: center; border-bottom: 1px solid #fa0; }
#logmsg table th.Corner { text-align: left; }
#logmsg hr { border: none 0; border-top: 2px dashed #fa0; height: 1px; }
#header, #footer { color: #fff; background: #636; border: 1px #300 solid; padding: 6px; }
#patch { width: 100%; }
#patch h4 {font-family: verdana,arial,helvetica,sans-serif;font-size:10pt;padding:8px;background:#369;color:#fff;margin:0;}
#patch .propset h4, #patch .binary h4 {margin:0;}
#patch pre {padding:0;line-height:1.2em;margin:0;}
#patch .diff {width:100%;background:#eee;padding: 0 0 10px 0;overflow:auto;}
#patch .propset .diff, #patch .binary .diff {padding:10px 0;}
#patch span {display:block;padding:0 10px;}
#patch .modfile, #patch .addfile, #patch .delfile, #patch .propset, #patch .binary, #patch .copfile {border:1px solid #ccc;margin:10px 0;}
#patch ins {background:#dfd;text-decoration:none;display:block;padding:0 10px;}
#patch del {background:#fdd;text-decoration:none;display:block;padding:0 10px;}
#patch .lines, .info {color:#888;background:#fff;}
--></style>
<div id="msg">
<dl class="meta">
<dt>Revision</dt> <dd><a href="http://trac.webkit.org/projects/webkit/changeset/165700">165700</a></dd>
<dt>Author</dt> <dd>fpizlo@apple.com</dd>
<dt>Date</dt> <dd>2014-03-16 09:49:16 -0700 (Sun, 16 Mar 2014)</dd>
</dl>
<h3>Log Message</h3>
<pre>FTL ArrayifyToStructure shouldn't fail every time that it actually arrayifies
https://bugs.webkit.org/show_bug.cgi?id=130296
Reviewed by Andreas Kling.
During the 32-bit structure ID work, the second load of the structure was removed.
That's wrong. The whole point of loading the structure ID again is that the structure
ID would have been changed by the arrayification call, and we're verifying that the
arrayification succeeded in changing the structure. If we check the old structure - as
the code was doing after the 32-bit structure ID work - then this check is guaranteed
to fail, causing a significant performance regression.
It's actually amazing that the regression wasn't bigger. The reason is that if FTL
code pathologically exits but the equivalent DFG code doesn't, then the exponential
backoff almost perfectly guarantees that we just end up in the DFG. For this code, at
the time at least, the DFG wasn't much slower so this didn't cause too much pain.
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileArrayifyToStructure):</pre>
<h3>Modified Paths</h3>
<ul>
<li><a href="#trunkSourceJavaScriptCoreChangeLog">trunk/Source/JavaScriptCore/ChangeLog</a></li>
<li><a href="#trunkSourceJavaScriptCoreftlFTLLowerDFGToLLVMcpp">trunk/Source/JavaScriptCore/ftl/FTLLowerDFGToLLVM.cpp</a></li>
</ul>
</div>
<div id="patch">
<h3>Diff</h3>
<a id="trunkSourceJavaScriptCoreChangeLog"></a>
<div class="modfile"><h4>Modified: trunk/Source/JavaScriptCore/ChangeLog (165699 => 165700)</h4>
<pre class="diff"><span>
<span class="info">--- trunk/Source/JavaScriptCore/ChangeLog 2014-03-16 16:38:58 UTC (rev 165699)
+++ trunk/Source/JavaScriptCore/ChangeLog 2014-03-16 16:49:16 UTC (rev 165700)
</span><span class="lines">@@ -1,5 +1,27 @@
</span><span class="cx"> 2014-03-15 Filip Pizlo <fpizlo@apple.com>
</span><span class="cx">
</span><ins>+ FTL ArrayifyToStructure shouldn't fail every time that it actually arrayifies
+ https://bugs.webkit.org/show_bug.cgi?id=130296
+
+ Reviewed by Andreas Kling.
+
+ During the 32-bit structure ID work, the second load of the structure was removed.
+ That's wrong. The whole point of loading the structure ID again is that the structure
+ ID would have been changed by the arrayification call, and we're verifying that the
+ arrayification succeeded in changing the structure. If we check the old structure - as
+ the code was doing after the 32-bit structure ID work - then this check is guaranteed
+ to fail, causing a significant performance regression.
+
+ It's actually amazing that the regression wasn't bigger. The reason is that if FTL
+ code pathologically exits but the equivalent DFG code doesn't, then the exponential
+ backoff almost perfectly guarantees that we just end up in the DFG. For this code, at
+ the time at least, the DFG wasn't much slower so this didn't cause too much pain.
+
+ * ftl/FTLLowerDFGToLLVM.cpp:
+ (JSC::FTL::LowerDFGToLLVM::compileArrayifyToStructure):
+
+2014-03-15 Filip Pizlo <fpizlo@apple.com>
+
</ins><span class="cx"> FTL should support CheckHasInstance/InstanceOf
</span><span class="cx"> https://bugs.webkit.org/show_bug.cgi?id=130285
</span><span class="cx">
</span></span></pre></div>
<a id="trunkSourceJavaScriptCoreftlFTLLowerDFGToLLVMcpp"></a>
<div class="modfile"><h4>Modified: trunk/Source/JavaScriptCore/ftl/FTLLowerDFGToLLVM.cpp (165699 => 165700)</h4>
<pre class="diff"><span>
<span class="info">--- trunk/Source/JavaScriptCore/ftl/FTLLowerDFGToLLVM.cpp 2014-03-16 16:38:58 UTC (rev 165699)
+++ trunk/Source/JavaScriptCore/ftl/FTLLowerDFGToLLVM.cpp 2014-03-16 16:49:16 UTC (rev 165700)
</span><span class="lines">@@ -1657,6 +1657,7 @@
</span><span class="cx"> break;
</span><span class="cx"> }
</span><span class="cx">
</span><ins>+ structureID = m_out.load32(cell, m_heaps.JSCell_structureID);
</ins><span class="cx"> speculate(
</span><span class="cx"> BadIndexingType, jsValueValue(cell), 0,
</span><span class="cx"> m_out.notEqual(structureID, weakStructure(m_node->structure())));
</span></span></pre>
</div>
</div>
</body>
</html>