<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">I think there are no guarantees for NaN preservation. See for example:</div><div class=""><br class=""></div><a href="https://lists.llvm.org/pipermail/llvm-dev/2014-September/076783.html" class="">https://lists.llvm.org/pipermail/llvm-dev/2014-September/076783.html</a><div class=""><br class=""></div><div class="">That said I assume we will take patches that fix bugs in the area if they don't cause any other problems.</div><div class=""><br class=""></div><div class="">- Matthias</div><div class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Nov 9, 2018, at 2:30 PM, Cameron McInally via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">On Fri, Nov 9, 2018 at 5:04 PM Thomas Lively via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:<br class=""><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class=""><div dir="ltr" class="">Hi everyone,<div class=""><br class=""></div><div class="">The WebAssembly backend recently had <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.llvm.org_show-5Fbug.cgi-3Fid-3D39448&d=DwMFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=O_4M49EtSpZ_-BQYeigzGv0P4__noMcSu2RYEjS1vKs&m=EMgUA8z--r1FpY6G3GJoEnyqkZVzDdmp_RZtq9yil0A&s=XKwt_z7tgU3TYfcuh43NOtFCMsGvtwmcKNdcqIOHcvc&e=" target="_blank" class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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><div class=""><br class=""></div><div class="">Our out-of-tree compiler encodes information into the mantissa of a NaN. E.g. what caused the NaN to be created. This helps us track down the problematic code and has been useful in the past.</div></div></div>
_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<br class=""></div></blockquote></div><br class=""></div></body></html>