
<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">

<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>

</head>

<body dir="ltr">

<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif;" dir="ltr">

<p style="margin-top:0;margin-bottom:0">One issue is that currently none (except one I think I added) of the functions in APFloat properly preserve payload bits so I think the problem is bigger than late corruption if you are expecting these to behave as expected.</p>

<p style="margin-top:0;margin-bottom:0"><br>

</p>

<p style="margin-top:0;margin-bottom:0">-Matt</p>

</div>

<hr style="display:inline-block;width:98%" tabindex="-1">

<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> llvm-dev <llvm-dev-bounces@lists.llvm.org> on behalf of Thomas Lively via llvm-dev <llvm-dev@lists.llvm.org><br>

<b>Sent:</b> Friday, November 9, 2018 2:04:11 PM<br>

<b>To:</b> llvm-dev@lists.llvm.org<br>

<b>Subject:</b> [llvm-dev] Should NaN payloads be preserved through compilation?</font>

<div> </div>

</div>

<div>

<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">

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><br>

</div>

<div>Thomas</div>

</div>

</div>

</div>

</body>

</html>