On Wed, Aug 29, 2018 at 3:13 PM, Cameron McInally <cameron.mcinally at nyu.edu> wrote:> On Wed, Aug 29, 2018 at 1:51 PM, Stephen Canon <scanon at apple.com> wrote: > >> On Aug 29, 2018, at 1:22 PM, Cameron McInally via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >> >> FSUB(-0.0, NaN) = NaN >> FSUB(-0.0, -NaN) = NaN >> >> >> Some specific architecture may define this, or APFloat might, but IEEE >> 754 does not interpret the sign of NaN except in four operations (copy, >> abs, negate, copysign), so it doesn’t say anything about these. >> > > Good point. I suppose one could argue that the behavior is undefined. >Apologies, I was wrong about this one. Just tested the FSUB hardware instruction on all the targets I care about and they all respect the sign on NaNs. I'm not sure how this got into my head... -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180830/8217b86a/attachment.html>
On Thu, Aug 30, 2018, 8:03 AM Cameron McInally via llvm-dev < llvm-dev at lists.llvm.org> wrote:> On Wed, Aug 29, 2018 at 3:13 PM, Cameron McInally < > cameron.mcinally at nyu.edu> wrote: > >> On Wed, Aug 29, 2018 at 1:51 PM, Stephen Canon <scanon at apple.com> wrote: >> >>> On Aug 29, 2018, at 1:22 PM, Cameron McInally via llvm-dev < >>> llvm-dev at lists.llvm.org> wrote: >>> >>> >>> FSUB(-0.0, NaN) = NaN >>> FSUB(-0.0, -NaN) = NaN >>> >>> >>> Some specific architecture may define this, or APFloat might, but IEEE >>> 754 does not interpret the sign of NaN except in four operations (copy, >>> abs, negate, copysign), so it doesn’t say anything about these. >>> >> >> Good point. I suppose one could argue that the behavior is undefined. >> > > Apologies, I was wrong about this one. Just tested the FSUB hardware > instruction on all the targets I care about and they all respect the sign > on NaNs. I'm not sure how this got into my head... >No, you weren't wrong. The sign of the NaN result is only defined, per the standard, for those 4 operations, no others. Certain hardware or certain ISAs may make more guarantees, of course. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180830/4f14d8f4/attachment.html>
On Thu, Aug 30, 2018 at 9:28 AM, James Y Knight <jyknight at google.com> wrote:> > > On Thu, Aug 30, 2018, 8:03 AM Cameron McInally via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> On Wed, Aug 29, 2018 at 3:13 PM, Cameron McInally < >> cameron.mcinally at nyu.edu> wrote: >> >>> On Wed, Aug 29, 2018 at 1:51 PM, Stephen Canon <scanon at apple.com> wrote: >>> >>>> On Aug 29, 2018, at 1:22 PM, Cameron McInally via llvm-dev < >>>> llvm-dev at lists.llvm.org> wrote: >>>> >>>> >>>> FSUB(-0.0, NaN) = NaN >>>> FSUB(-0.0, -NaN) = NaN >>>> >>>> >>>> Some specific architecture may define this, or APFloat might, but IEEE >>>> 754 does not interpret the sign of NaN except in four operations (copy, >>>> abs, negate, copysign), so it doesn’t say anything about these. >>>> >>> >>> Good point. I suppose one could argue that the behavior is undefined. >>> >> >> Apologies, I was wrong about this one. Just tested the FSUB hardware >> instruction on all the targets I care about and they all respect the sign >> on NaNs. I'm not sure how this got into my head... >> > > No, you weren't wrong. > > The sign of the NaN result is only defined, per the standard, for those 4 > operations, no others. Certain hardware or certain ISAs may make more > guarantees, of course. >Yeah, of course, but I'm a pragmatist. ;) Kidding aside, I've heard a handful of yeas for adding an explicit FNEG instruction. Are there any nays (or maybes) out there? I'd like to hear those concerns... -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180830/c003b3eb/attachment.html>
On Thu, 30 Aug 2018 at 05:02, Cameron McInally <cameron.mcinally at nyu.edu> wrote:> > On Wed, Aug 29, 2018 at 3:13 PM, Cameron McInally <cameron.mcinally at nyu.edu> wrote: >> >> On Wed, Aug 29, 2018 at 1:51 PM, Stephen Canon <scanon at apple.com> wrote: >>> >>> On Aug 29, 2018, at 1:22 PM, Cameron McInally via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> >>> >>> FSUB(-0.0, NaN) = NaN >>> FSUB(-0.0, -NaN) = NaN >>> >>> >>> Some specific architecture may define this, or APFloat might, but IEEE 754 does not interpret the sign of NaN except in four operations (copy, abs, negate, copysign), so it doesn’t say anything about these. >> >> >> Good point. I suppose one could argue that the behavior is undefined. > > > Apologies, I was wrong about this one. Just tested the FSUB hardware instruction on all the targets I care about and they all respect the sign on NaNs. I'm not sure how this got into my head...I don't think it matters for the question at hand, but I tested AArch64 too and it exhibits the behaviour you were describing. That is, we'd have problems if an fsub -0.0 was actually CodeGened like that (it's not, of course). Tim.
On Thu, Aug 30, 2018 at 11:14 AM, Tim Northover <t.p.northover at gmail.com> wrote:> ... > I don't think it matters for the question at hand, but I tested > AArch64 too and it exhibits the behaviour you were describing. That > is, we'd have problems if an fsub -0.0 was actually CodeGened like > that (it's not, of course).Great data point. So it's not just a theoretical problem. Thanks, Tim! -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180830/e46f8791/attachment.html>