<!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>[212877] 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/212877">212877</a></dd>
<dt>Author</dt> <dd>jfbastien@apple.com</dd>
<dt>Date</dt> <dd>2017-02-22 22:35:50 -0800 (Wed, 22 Feb 2017)</dd>
</dl>
<h3>Log Message</h3>
<pre>WebAssembly: clear out insignificant i32 bits when calling JavaScript
https://bugs.webkit.org/show_bug.cgi?id=166677
Reviewed by Keith Miller.
When WebAssembly calls JavaScript it needs to clear out the
insignificant bits of int32 values:
+------------------- tag
| +---------------- insignificant
| | +------------ 32-bit integer value
| | |
|--|---|-------|
0xffff0000ffffffff
At least some JavaScript code assumes that these bits are all
zero. In the wasm-to-wasm.js example we store a 64-bit value in an
object with lo / hi fields, each containing 32-bit integers. We
then load these back, and the baseline compiler fails its
comparison because it first checks the value are the same type
(yes, because the int32 tag is set in both), and then whether they
have the same value (no, because comparing the two registers
fails). We could argue that the baseline compiler is wrong for
performing a 64-bit comparison, but it doesn't really matter
because there's not much of a point in breaking that invariant for
WebAssembly's sake.
* wasm/WasmBinding.cpp:
(JSC::Wasm::wasmToJs):</pre>
<h3>Modified Paths</h3>
<ul>
<li><a href="#trunkSourceJavaScriptCoreChangeLog">trunk/Source/JavaScriptCore/ChangeLog</a></li>
<li><a href="#trunkSourceJavaScriptCorewasmWasmBindingcpp">trunk/Source/JavaScriptCore/wasm/WasmBinding.cpp</a></li>
</ul>
</div>
<div id="patch">
<h3>Diff</h3>
<a id="trunkSourceJavaScriptCoreChangeLog"></a>
<div class="modfile"><h4>Modified: trunk/Source/JavaScriptCore/ChangeLog (212876 => 212877)</h4>
<pre class="diff"><span>
<span class="info">--- trunk/Source/JavaScriptCore/ChangeLog 2017-02-23 06:11:02 UTC (rev 212876)
+++ trunk/Source/JavaScriptCore/ChangeLog 2017-02-23 06:35:50 UTC (rev 212877)
</span><span class="lines">@@ -1,3 +1,35 @@
</span><ins>+2017-02-22 JF Bastien <jfbastien@apple.com>
+
+ WebAssembly: clear out insignificant i32 bits when calling JavaScript
+ https://bugs.webkit.org/show_bug.cgi?id=166677
+
+ Reviewed by Keith Miller.
+
+ When WebAssembly calls JavaScript it needs to clear out the
+ insignificant bits of int32 values:
+
+ +------------------- tag
+ | +---------------- insignificant
+ | | +------------ 32-bit integer value
+ | | |
+ |--|---|-------|
+ 0xffff0000ffffffff
+
+ At least some JavaScript code assumes that these bits are all
+ zero. In the wasm-to-wasm.js example we store a 64-bit value in an
+ object with lo / hi fields, each containing 32-bit integers. We
+ then load these back, and the baseline compiler fails its
+ comparison because it first checks the value are the same type
+ (yes, because the int32 tag is set in both), and then whether they
+ have the same value (no, because comparing the two registers
+ fails). We could argue that the baseline compiler is wrong for
+ performing a 64-bit comparison, but it doesn't really matter
+ because there's not much of a point in breaking that invariant for
+ WebAssembly's sake.
+
+ * wasm/WasmBinding.cpp:
+ (JSC::Wasm::wasmToJs):
+
</ins><span class="cx"> 2017-02-22 Keith Miller <keith_miller@apple.com>
</span><span class="cx">
</span><span class="cx"> Remove the demand executable allocator
</span></span></pre></div>
<a id="trunkSourceJavaScriptCorewasmWasmBindingcpp"></a>
<div class="modfile"><h4>Modified: trunk/Source/JavaScriptCore/wasm/WasmBinding.cpp (212876 => 212877)</h4>
<pre class="diff"><span>
<span class="info">--- trunk/Source/JavaScriptCore/wasm/WasmBinding.cpp 2017-02-23 06:11:02 UTC (rev 212876)
+++ trunk/Source/JavaScriptCore/wasm/WasmBinding.cpp 2017-02-23 06:35:50 UTC (rev 212877)
</span><span class="lines">@@ -155,6 +155,7 @@
</span><span class="cx"> frOffset += sizeof(Register);
</span><span class="cx"> }
</span><span class="cx"> ++marshalledGPRs;
</span><ins>+ jit.zeroExtend32ToPtr(gprReg, gprReg); // Clear non-int32 and non-tag bits.
</ins><span class="cx"> jit.boxInt32(gprReg, JSValueRegs(gprReg), DoNotHaveTagRegisters);
</span><span class="cx"> jit.store64(gprReg, calleeFrame.withOffset(calleeFrameOffset));
</span><span class="cx"> calleeFrameOffset += sizeof(Register);
</span></span></pre>
</div>
</div>
</body>
</html>