llvm dev - Jan 2015 - [LLVMdev] [PATCH] [ADT] APFloat - Fix sign handling for FMA results that truncate to zero.

Hi All,

APFloat::fusedMultiplyAdd currently computes the wrong signed zero when
small negative results are truncated back to zero in standard precision.
The following snippet handles the signedness in fusedMultiplyAdd:

/* If two numbers add (exactly) to zero, IEEE 754 decrees it is a
   positive zero unless rounding to minus infinity, except that

   adding two like-signed zeroes gives that zero.  */
if (category == fcZero && sign != addend.sign)
  sign = (rounding_mode == rmTowardNegative);

The test "category == fcZero" tells us that the result was zero after
rounding back down to standard precision, but since the addition is carried
out in extended precision this doesn't guarantee that the result of the
addition was exactly zero (so the comment text may not apply). The attached
patch adds a check for underflow during truncation which ensures the
correct signedness of the result.

Cheers,
Lang.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150101/6b879295/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: APFloat_FMA_truncated_zero_sign.patch
Type: application/octet-stream
Size: 1476 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150101/6b879295/attachment.obj>

Hi Lang,
> On Jan 1, 2015, at 5:57 PM, Lang Hames <lhames at gmail.com> wrote:
> 
> Hi All,
> 
> APFloat::fusedMultiplyAdd currently computes the wrong signed zero when
small negative results are truncated back to zero in standard precision. The
following snippet handles the signedness in fusedMultiplyAdd:
> 
> /* If two numbers add (exactly) to zero, IEEE 754 decrees it is a
>    positive zero unless rounding to minus infinity, except that
>    adding two like-signed zeroes gives that zero.  */
> if (category == fcZero && sign != addend.sign)
>   sign = (rounding_mode == rmTowardNegative);
> 
> The test "category == fcZero" tells us that the result was zero
after rounding back down to standard precision, but since the addition is
carried out in extended precision this doesn't guarantee that the result of
the addition was exactly zero (so the comment text may not apply). The attached
patch adds a check for underflow during truncation which ensures the correct
signedness of the result.

According to what you describe ("the comment text may not apply"), I
feel that the comment might be updated as well.

Best,

Mehdi

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150101/6cba4862/attachment.html>

Hi Mehdi,

Thanks for the feedback. I think the comment is fine - the problem is just
that the original conditional didn't exactly match it. With the addition of
the underflow check I believe the condition now matches the comment: The
sign is only tweaked if the result of the addition is exactly zero, rather
than a small result that truncates to zero.

CC'ing llvm-commits, where this email should have gone in the first place.
:)

Cheers,
Lang.

On Thu, Jan 1, 2015 at 10:56 PM, Mehdi Amini <mehdi.amini at apple.com>
wrote:
> Hi Lang,
>
> On Jan 1, 2015, at 5:57 PM, Lang Hames <lhames at gmail.com> wrote:
>
> Hi All,
>
> APFloat::fusedMultiplyAdd currently computes the wrong signed zero when
> small negative results are truncated back to zero in standard precision.
> The following snippet handles the signedness in fusedMultiplyAdd:
>
> /* If two numbers add (exactly) to zero, IEEE 754 decrees it is a
>    positive zero unless rounding to minus infinity, except that
>
>    adding two like-signed zeroes gives that zero.  */
> if (category == fcZero && sign != addend.sign)
>   sign = (rounding_mode == rmTowardNegative);
>
> The test "category == fcZero" tells us that the result was zero
after
> rounding back down to standard precision, but since the addition is carried
> out in extended precision this doesn't guarantee that the result of the
> addition was exactly zero (so the comment text may not apply). The attached
> patch adds a check for underflow during truncation which ensures the
> correct signedness of the result.
>
>
>
> According to what you describe ("the comment text may not
apply"), I feel
> that the comment might be updated as well.
>
> Best,
>
> Mehdi
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150102/ed6a1ab2/attachment.html>