On Wed, 29 Aug 2018 at 07:51, Cameron McInally via llvm-dev <llvm-dev at lists.llvm.org> wrote:> The current thinking is that FNEG(X) and FSUB(-0.0, X) are not the same operation when X is a NaN or 0.Do you mean denormals (when flushed) rather than 0 there? AFAIK it's OK for 0 itself.> So, the xforms in question should only be valid under Fast-Math conditions.We could probably also "fix" the issue by taking the view that LLVM's fsub provides extra guarantees for NaN over the IEEE-754 one. I.e. that "fsub -0.0, x" behaves as negate. I believe that would still be conformant to IEEE-754 and not require any actual changes in LLVM (since it's what CPUs would do anyway). I think that's uglier than adding FNEG though.> Is correcting this behavior something that the general LLVM population would like? If not, we can create constrained intrinsics for the FPEnv project.I'm in favour of FNEG too. I remember the fsub trick being confusing when I first encountered it. Cheers. Tim.
> On Aug 29, 2018, at 12:16 PM, Tim Northover via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Wed, 29 Aug 2018 at 07:51, Cameron McInally via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > >> The current thinking is that FNEG(X) and FSUB(-0.0, X) are not the same operation when X is a NaN or 0. > > Do you mean denormals (when flushed) rather than 0 there? AFAIK it's > OK for 0 itself.Under the assumption of default rounding, yes.>> So, the xforms in question should only be valid under Fast-Math conditions. > > We could probably also "fix" the issue by taking the view that LLVM's > fsub provides extra guarantees for NaN over the IEEE-754 one. I.e. > that "fsub -0.0, x" behaves as negate. I believe that would still be > conformant to IEEE-754 and not require any actual changes in LLVM > (since it's what CPUs would do anyway). > > I think that's uglier than adding FNEG though.NaN doesn’t need special handling except in the presence of signaling NaNs, where the IEEE-754 negate operation would produce a signaling NaN rather than a quiet NaN + invalid flag. Again, under the default fenv assumption, nothing special is needed.>> Is correcting this behavior something that the general LLVM population would like? If not, we can create constrained intrinsics for the FPEnv project. > > I'm in favour of FNEG too. I remember the fsub trick being confusing > when I first encountered it.We should still do fneg, though, because this. – Steve
On Wed, Aug 29, 2018 at 12:16 PM, Tim Northover <t.p.northover at gmail.com> wrote:> On Wed, 29 Aug 2018 at 07:51, Cameron McInally via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > The current thinking is that FNEG(X) and FSUB(-0.0, X) are not the same > operation when X is a NaN or 0. > > Do you mean denormals (when flushed) rather than 0 there? AFAIK it's > OK for 0 itself.Bah, you're correct. 0s are fine. That's assuming the xform is always to FSUB(-0.0,X) and not FSUB(0.0,X). NaNs are not ok. I.e.: FNEG( NaN) = -NaN FNEG(-NaN) = NaN FSUB(-0.0, NaN) = NaN FSUB(-0.0, -NaN) = NaN Thanks for the correction, Tim. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180829/4c50066c/attachment.html>
> 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) = NaNSome 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. – Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180829/843b4613/attachment.html>