llvm dev - Nov 2018 - Should NaN payloads be preserved through compilation?

Hi everyone,

The WebAssembly backend recently had Bug 39448
<https://bugs.llvm.org/show_bug.cgi?id=39448> 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?

Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20181109/50c738b2/attachment.html>

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.


-Matt

________________________________
From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Thomas
Lively via llvm-dev <llvm-dev at lists.llvm.org>
Sent: Friday, November 9, 2018 2:04:11 PM
To: llvm-dev at lists.llvm.org
Subject: [llvm-dev] Should NaN payloads be preserved through compilation?

Hi everyone,

The WebAssembly backend recently had Bug
39448<https://bugs.llvm.org/show_bug.cgi?id=39448> 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?

Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20181109/b22ba221/attachment.html>

Thanks, Matt, that's good to know. If we only consider immediates that are
not modified by optimization passes, perhaps the problem is more tractable.
In my brief exploration, it appeared that the custom NaN payloads of the
immediates were intact up until that conversion in the MC layer.

On Fri, Nov 9, 2018 at 2:10 PM Arsenault, Matthew <Matthew.Arsenault at
amd.com>
wrote:
> 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.
>
>
> -Matt
> ------------------------------
> *From:* llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of
Thomas
> Lively via llvm-dev <llvm-dev at lists.llvm.org>
> *Sent:* Friday, November 9, 2018 2:04:11 PM
> *To:* llvm-dev at lists.llvm.org
> *Subject:* [llvm-dev] Should NaN payloads be preserved through
> compilation?
>
> Hi everyone,
>
> The WebAssembly backend recently had Bug 39448
> <https://bugs.llvm.org/show_bug.cgi?id=39448> 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?
>
> Thomas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20181109/e8a8ee4b/attachment.html>

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>

On 11/9/2018 2:04 PM, Thomas Lively via llvm-dev wrote:
> Hi everyone,
>
> The WebAssembly backend recently had Bug 39448 
> <https://bugs.llvm.org/show_bug.cgi?id=39448> 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?
Seems fine, as long as you don't increase the size of MCOperand. 
(MachineOperand already uses ConstantFP, so it should be a tiny patch.)

-Eli

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20181109/0cca684f/attachment-0001.html>

I think there are no guarantees for NaN preservation. See for example:

https://lists.llvm.org/pipermail/llvm-dev/2014-September/076783.html
<https://lists.llvm.org/pipermail/llvm-dev/2014-September/076783.html>

That said I assume we will take patches that fix bugs in the area if they
don't cause any other problems.

- Matthias

> On Nov 9, 2018, at 2:30 PM, Cameron McInally via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> On Fri, Nov 9, 2018 at 5:04 PM Thomas Lively via llvm-dev <llvm-dev at
lists.llvm.org <mailto: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.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20181109/5108411f/attachment.html>