Hey llvm-dev, Continuing a discussion from D50913... A group working on the FP rounding mode and trap-safety project have run into a situation where it would make sense to add a new FNEG instruction and decouple the existing FNEG<->FSUB transformations. The IEEE-754 Standard (Section 5.5.1) makes it clear that neg(x) and sub(-0.0,x) are two different operations. The former is a bitwise operation, while the latter is an arithmetic operation. That said, LLVM currently conflates the two operations in several places. It would be nice to separate the two operations to give the user explicit control over which type of operation is generated. D50913 covers a lot of ground, so I'll leave the discussion here for now until any interested parties are up to speed. Thanks for looking, Cameron -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180821/9c1fd563/attachment.html>
Ping... The current thinking is that FNEG(X) and FSUB(-0.0, X) are not the same operation when X is a NaN or 0. So, the xforms in question should only be valid under Fast-Math conditions. Is correcting this behavior something that the general LLVM population would like? If not, we can create constrained intrinsics for the FPEnv project. Thanks again, Cameron On Tue, Aug 21, 2018 at 12:17 PM, Cameron McInally <cameron.mcinally at nyu.edu> wrote:> Hey llvm-dev, > > Continuing a discussion from D50913... > > A group working on the FP rounding mode and trap-safety project have run > into a situation where it would make sense to add a new FNEG instruction > and decouple the existing FNEG<->FSUB transformations. > > The IEEE-754 Standard (Section 5.5.1) makes it clear that neg(x) and > sub(-0.0,x) are two different operations. The former is a bitwise > operation, while the latter is an arithmetic operation. > > That said, LLVM currently conflates the two operations in several places. > It would be nice to separate the two operations to give the user explicit > control over which type of operation is generated. > > D50913 covers a lot of ground, so I'll leave the discussion here for now > until any interested parties are up to speed. > > Thanks for looking, > Cameron >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180829/9d4b2c68/attachment.html>
> On Aug 29, 2018, at 17:50, Cameron McInally via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Ping... > > The current thinking is that FNEG(X) and FSUB(-0.0, X) are not the same operation when X is a NaN or 0. So, the xforms in question should only be valid under Fast-Math conditions. > > Is correcting this behavior something that the general LLVM population would like? If not, we can create constrained intrinsics for the FPEnv project. > > Thanks again, > Cameron+1
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.