[llvm-dev] Should NaN payloads be preserved through compilation?

[Cameron McInally via llvm-dev]

On Fri, Nov 9, 2018 at 5:04 PM Thomas Lively via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hi everyone,
>
> The WebAssembly backend recently had Bug 39448
> <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=> 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.
>
> 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.
>
> 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?
>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181109/da7ca1cd/attachment.html>