<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 11/9/2018 2:04 PM, Thomas Lively via
llvm-dev wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAJZD_EW=7o0ixxv91=MT8rPYWCMyB4Sf0Nbg2U1YxziKVxWh8Q@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr">Hi everyone,
<div><br>
</div>
<div>The WebAssembly backend recently had <a
href="https://bugs.llvm.org/show_bug.cgi?id=39448"
moz-do-not-send="true">Bug 39448</a> filed against it
because NaN payloads in floating-point immediates are not
preserved through compilation on 32-bit builds. I took a
look and the corruption takes place when the immediates are
converted from APFloats to be stored as native doubles in
MCOperand. I assume this bug only appears in 32-bit builds
because they are using x87 doubles that happen to not
preserve all possible NaN payloads.</div>
<div><br>
</div>
<div>There are two things we could do here: Change MCOperand
to not store floating point immediates as native doubles, or
explicitly accept that NaN payloads in immediates will not
necessarily be preserved through compilation.</div>
<div><br>
</div>
<div>The ability to have custom NaN payloads in immediates
could be useful to the WebAssembly community, but if the
consensus is that LLVM should not guarantee their
preservation, that's fine too. What do you think?</div>
</div>
</div>
</blockquote>
<p>Seems fine, as long as you don't increase the size of MCOperand.
(MachineOperand already uses ConstantFP, so it should be a tiny
patch.)<br>
</p>
<p>-Eli<br>
</p>
<pre class="moz-signature" cols="72">--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project</pre>
</body>
</html>