In r187314, APFloat multiplication by with NaNs was made to always yield a positive NaN. I am wondering whether that was the correct decision. It is of course true that the result of a multiplication is undefined in IEEE, however, we were using multiplication by -1.0 to implement IEEE negate, which is defined to preserve the sign bit. r210428 made 0-NaN have IEEE negate behavior, which is good because it seems to me from r187314 to r210428 there was no compliant way to implement it in LLVM. Does somebody remember what the arguments for the behavior change in r187314 were? It seems more sane to me to preserve the sign bit than to unconditionally overwrite it, especially considering that the hardware doesn't do it this way. Thanks, Keno
Hi Keno,>From IEEE 754-2008, §5.5.1:Implementations shall provide the following homogeneous quiet-computational sign bit operations for all supported arithmetic formats; they only affect the sign bit. The operations treat floating-point numbers and NaNs alike, and signal no exception. These operations may propagate non-canonical encodings. sourceFormat copy(source) sourceFormat negate(source) sourceFormat abs(source) Multiplying by -1.0 has the potential to raise a floating point exception on sNaN inputs, and hence is not a valid implementation of negation per IEEE 754. —Owen On Aug 6, 2014, at 9:51 PM, Keno Fischer <kfischer at college.harvard.edu> wrote:> In r187314, APFloat multiplication by with NaNs was made to always > yield a positive NaN. I am wondering whether that was the correct > decision. It is of course true that the result of a multiplication is > undefined in IEEE, however, we were using multiplication by -1.0 to > implement IEEE negate, which is defined to preserve the sign bit. > r210428 made 0-NaN have IEEE negate behavior, which is good because it > seems to me from r187314 to r210428 there was no compliant way to > implement it in LLVM. Does somebody remember what the arguments for > the behavior change in r187314 were? It seems more sane to me to > preserve the sign bit than to unconditionally overwrite it, especially > considering that the hardware doesn't do it this way. > > Thanks, > Keno > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Ok, I had forgotten about sNaNs. Doesn't the same caveat apply to 0-sNaN then though or does that not signal? Does that mean we need a separate way to handle negate in the IR? Funnily enough, historically I believe we were using the multiplication by -1.0 because it was a more reliable negation that 0-x (from 3.0 until 3.3 at least). Is there a good reason why multiplication by NaN should kill the sign bit? On Thu, Aug 7, 2014 at 1:22 AM, Owen Anderson <resistor at mac.com> wrote:> Hi Keno, > > From IEEE 754-2008, §5.5.1: > Implementations shall provide the following homogeneous quiet-computational sign bit operations for all > supported arithmetic formats; they only affect the sign bit. The operations treat floating-point numbers and > NaNs alike, and signal no exception. These operations may propagate non-canonical encodings. > > sourceFormat copy(source) > sourceFormat negate(source) > sourceFormat abs(source) > > Multiplying by -1.0 has the potential to raise a floating point exception on sNaN inputs, and hence is not a valid implementation of negation per IEEE 754. > > —Owen > > On Aug 6, 2014, at 9:51 PM, Keno Fischer <kfischer at college.harvard.edu> wrote: > >> In r187314, APFloat multiplication by with NaNs was made to always >> yield a positive NaN. I am wondering whether that was the correct >> decision. It is of course true that the result of a multiplication is >> undefined in IEEE, however, we were using multiplication by -1.0 to >> implement IEEE negate, which is defined to preserve the sign bit. >> r210428 made 0-NaN have IEEE negate behavior, which is good because it >> seems to me from r187314 to r210428 there was no compliant way to >> implement it in LLVM. Does somebody remember what the arguments for >> the behavior change in r187314 were? It seems more sane to me to >> preserve the sign bit than to unconditionally overwrite it, especially >> considering that the hardware doesn't do it this way. >> >> Thanks, >> Keno >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >