<!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>[195446] 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/195446">195446</a></dd>
<dt>Author</dt> <dd>benjamin@webkit.org</dd>
<dt>Date</dt> <dd>2016-01-21 23:24:36 -0800 (Thu, 21 Jan 2016)</dd>
</dl>

<h3>Log Message</h3>
<pre>[JSC] The IRC allocator can mess up the degree of Tmps interfering with move-related Tmps
https://bugs.webkit.org/show_bug.cgi?id=153340

Reviewed by Filip Pizlo.

The JavaScriptCore tests uncovered an interested bug in the iterated register
coalescing allocator. When coalescing a move under the right conditions, it is
possible to mess-up the graph for the Tmps interfering with the coalesced Tmps.

Some context first:
-When coalescing a move, we alias one Tmp to another. Let say that we had
     Move X, Y
 the coalescing may alias Y to X: Y-&gt;X.
-Since X and Y are equivalent after coalescing, any interference
 edge with Y is &quot;moved&quot; to X.
 The way this was done was to add an edge to X for every edge there was with Y.
 Say we had an edge R--Y, we add an edge R--X.
 Adding an edge increases the degree of R and Y. The degree of R was then
 fixed by calling decrementDegree() on it.
-decrementDegree() is non trivial. It will move the Tmp to the right list
 for further processing if the Tmp's degree becomes lower than the number
 of available registers.

The bug appear in a particular case. Say we have 3 Tmp, A, B, and C.
-A and B are move related, they can be coalesced.
-A has an interference edge with C.
-B does not have and interfence edge with C.
-C's degree is exactly the number of avaialble registers/colors minus one (k - 1).
 -&gt; This implies C is already in its list.

We coalesce A and B into B (A-&gt;B).
-The first step, addEdgeDistinct() adds an edge between B and C. The degrees of
 B and C are increased by one. The degree of C becomes k.
-Next, decrementDegree() is called on C. Its degree decreases to k-1.
 Because of the change from k to k-1, decrementDegree() adds C to a list again.

We have two kinds of bugs depending on the test:
-A Tmp can be added to the simplifyWorklist several time.
-A Tmp can be in both simplifyWorklist and freezeWorklist (because its move-related
 status changed since the last decrementDegree()).
In both cases, the Tmps interfering with the duplicated Tmp will end up with
a degree lower than their real value.

* b3/air/AirIteratedRegisterCoalescing.cpp:</pre>

<h3>Modified Paths</h3>
<ul>
<li><a href="#trunkSourceJavaScriptCoreChangeLog">trunk/Source/JavaScriptCore/ChangeLog</a></li>
<li><a href="#trunkSourceJavaScriptCoreb3airAirIteratedRegisterCoalescingcpp">trunk/Source/JavaScriptCore/b3/air/AirIteratedRegisterCoalescing.cpp</a></li>
</ul>

</div>
<div id="patch">
<h3>Diff</h3>
<a id="trunkSourceJavaScriptCoreChangeLog"></a>
<div class="modfile"><h4>Modified: trunk/Source/JavaScriptCore/ChangeLog (195445 => 195446)</h4>
<pre class="diff"><span>
<span class="info">--- trunk/Source/JavaScriptCore/ChangeLog        2016-01-22 06:45:05 UTC (rev 195445)
+++ trunk/Source/JavaScriptCore/ChangeLog        2016-01-22 07:24:36 UTC (rev 195446)
</span><span class="lines">@@ -1,3 +1,50 @@
</span><ins>+2016-01-21  Benjamin Poulain  &lt;benjamin@webkit.org&gt;
+
+        [JSC] The IRC allocator can mess up the degree of Tmps interfering with move-related Tmps
+        https://bugs.webkit.org/show_bug.cgi?id=153340
+
+        Reviewed by Filip Pizlo.
+
+        The JavaScriptCore tests uncovered an interested bug in the iterated register
+        coalescing allocator. When coalescing a move under the right conditions, it is
+        possible to mess-up the graph for the Tmps interfering with the coalesced Tmps.
+
+        Some context first:
+        -When coalescing a move, we alias one Tmp to another. Let say that we had
+             Move X, Y
+         the coalescing may alias Y to X: Y-&gt;X.
+        -Since X and Y are equivalent after coalescing, any interference
+         edge with Y is &quot;moved&quot; to X.
+         The way this was done was to add an edge to X for every edge there was with Y.
+         Say we had an edge R--Y, we add an edge R--X.
+         Adding an edge increases the degree of R and Y. The degree of R was then
+         fixed by calling decrementDegree() on it.
+        -decrementDegree() is non trivial. It will move the Tmp to the right list
+         for further processing if the Tmp's degree becomes lower than the number
+         of available registers.
+
+        The bug appear in a particular case. Say we have 3 Tmp, A, B, and C.
+        -A and B are move related, they can be coalesced.
+        -A has an interference edge with C.
+        -B does not have and interfence edge with C.
+        -C's degree is exactly the number of avaialble registers/colors minus one (k - 1).
+         -&gt; This implies C is already in its list.
+
+        We coalesce A and B into B (A-&gt;B).
+        -The first step, addEdgeDistinct() adds an edge between B and C. The degrees of
+         B and C are increased by one. The degree of C becomes k.
+        -Next, decrementDegree() is called on C. Its degree decreases to k-1.
+         Because of the change from k to k-1, decrementDegree() adds C to a list again.
+
+        We have two kinds of bugs depending on the test:
+        -A Tmp can be added to the simplifyWorklist several time.
+        -A Tmp can be in both simplifyWorklist and freezeWorklist (because its move-related
+         status changed since the last decrementDegree()).
+        In both cases, the Tmps interfering with the duplicated Tmp will end up with
+        a degree lower than their real value.
+
+        * b3/air/AirIteratedRegisterCoalescing.cpp:
+
</ins><span class="cx"> 2016-01-21  Andreas Kling  &lt;akling@apple.com&gt;
</span><span class="cx"> 
</span><span class="cx">         Add some missing WTF_MAKE_FAST_ALLOCATED in JavaScriptCore.
</span></span></pre></div>
<a id="trunkSourceJavaScriptCoreb3airAirIteratedRegisterCoalescingcpp"></a>
<div class="modfile"><h4>Modified: trunk/Source/JavaScriptCore/b3/air/AirIteratedRegisterCoalescing.cpp (195445 => 195446)</h4>
<pre class="diff"><span>
<span class="info">--- trunk/Source/JavaScriptCore/b3/air/AirIteratedRegisterCoalescing.cpp        2016-01-22 06:45:05 UTC (rev 195445)
+++ trunk/Source/JavaScriptCore/b3/air/AirIteratedRegisterCoalescing.cpp        2016-01-22 07:24:36 UTC (rev 195446)
</span><span class="lines">@@ -291,6 +291,25 @@
</span><span class="cx">         }
</span><span class="cx">     }
</span><span class="cx"> 
</span><ins>+
+    bool addEdgeDistinctWithoutDegreeChange(IndexType a, IndexType b)
+    {
+        ASSERT(a != b);
+        if (m_interferenceEdges.add(InterferenceEdge(a, b)).isNewEntry) {
+            if (!isPrecolored(a)) {
+                ASSERT(!m_adjacencyList[a].contains(b));
+                m_adjacencyList[a].append(b);
+            }
+
+            if (!isPrecolored(b)) {
+                ASSERT(!m_adjacencyList[b].contains(a));
+                m_adjacencyList[b].append(a);
+            }
+            return true;
+        }
+        return false;
+    }
+
</ins><span class="cx">     bool isMoveRelated(IndexType tmpIndex)
</span><span class="cx">     {
</span><span class="cx">         for (unsigned moveIndex : m_moveList[tmpIndex]) {
</span><span class="lines">@@ -365,8 +384,19 @@
</span><span class="cx">         m_moveList[u].add(vMoves.begin(), vMoves.end());
</span><span class="cx"> 
</span><span class="cx">         forEachAdjacent(v, [this, u] (IndexType adjacentTmpIndex) {
</span><del>-            addEdgeDistinct(adjacentTmpIndex, u);
-            decrementDegree(adjacentTmpIndex);
</del><ins>+            if (addEdgeDistinctWithoutDegreeChange(adjacentTmpIndex, u)) {
+                // If we added a new edge between the adjacentTmp and u, it replaces the edge
+                // that existed with v.
+                // The degree of adjacentTmp remains the same since the edge just changed from u to v.
+                // All we need to do is update the degree of u.
+                if (!isPrecolored(u))
+                    m_degrees[u]++;
+            } else {
+                // If we already had an edge between the adjacentTmp and u, the degree of u
+                // is already correct. The degree of the adjacentTmp decreases since the edge
+                // with v is no longer relevant (we can think of it as merged with the edge with u).
+                decrementDegree(adjacentTmpIndex);
+            }
</ins><span class="cx">         });
</span><span class="cx"> 
</span><span class="cx">         if (m_degrees[u] &gt;= m_regsInPriorityOrder.size() &amp;&amp; m_freezeWorklist.remove(u))
</span></span></pre>
</div>
</div>

</body>
</html>