llvm dev - Jun 2013 - [LLVMdev] round() vs. rint()/nearbyint() with fast-math

On Fri, Jun 21, 2013 at 7:54 AM, David Tweed <david.tweed at arm.com>
wrote:
> | LLVM does not currently have special lowering handling for round(), and
> I'll propose a patch to add that, but the larger question is this:
should
> fast-math change the tie-breaking behavior of
> | rint/nearbyint/round, etc. and, if so, should we make a specific effort
> to
> have all backends provide the same guarantee (or lack of a guarantee) in
> this regard?
>
> I don't know, primarily because I've never really been involved in
anything
> where I've cared about using exotic rounding modes. But in general
I'm of
> the opinion that -fast-math is the "nuclear option" that's
allowed to do
> lots of things which may well invoke backend specific behaviour.
(That's
> also why I think that most FP transformations shouldn't be
"only" guarded
> by
> fast-math but a more precise option.)

The functions rint and round and standard libm functions commonly used to
round floating point values to integers. Both round to the nearest integer,
but break ties differently -- rint uses IEEE tie breaking (towards even),
round uses mathematical tie breaking (away from zero).

The question here is: Is this optimization worthwhile, or would it surprise
too many people? Depending on this, it should either be disallowed, or
possibly implemented for other back-ends as well.

-erik

-- 
Erik Schnetter <schnetter at cct.lsu.edu>
http://www.perimeterinstitute.ca/personal/eschnetter/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130621/768d3be1/attachment.html>

On Fri, Jun 21, 2013 at 5:11 PM, Erik Schnetter <schnetter at
cct.lsu.edu>wrote:
> On Fri, Jun 21, 2013 at 7:54 AM, David Tweed <david.tweed at arm.com>
wrote:
>
>> | LLVM does not currently have special lowering handling for round(),
and
>> I'll propose a patch to add that, but the larger question is this:
should
>> fast-math change the tie-breaking behavior of
>> | rint/nearbyint/round, etc. and, if so, should we make a specific
effort
>> to
>> have all backends provide the same guarantee (or lack of a guarantee)
in
>> this regard?
>>
>> I don't know, primarily because I've never really been involved
in
>> anything
>> where I've cared about using exotic rounding modes. But in general
I'm of
>> the opinion that -fast-math is the "nuclear option"
that's allowed to do
>> lots of things which may well invoke backend specific behaviour.
(That's
>> also why I think that most FP transformations shouldn't be
"only" guarded
>> by
>> fast-math but a more precise option.)
>
>
> The functions rint and round and standard libm functions commonly used to
> round floating point values to integers. Both round to the nearest integer,
> but break ties differently -- rint uses IEEE tie breaking (towards even),
> round uses mathematical tie breaking (away from zero).
>
> The question here is: Is this optimization worthwhile, or would it
> surprise too many people? Depending on this, it should either be
> disallowed, or possibly implemented for other back-ends as well.
>
After some consideration, I have come to the conclusion that this
optimization (changing rint to round) is not worthwhile. There are some
floating point operations that can provide an exact result, and not
obtaining this exact result is surprising. For example, I would expect that
adding/multiplying two small integers gives the exact result, or that
fmin/fmax give the correct result if no nans are involved, or that
comparisons yield the correct answer (again in the absence of nans,
denormalized numbers etc.).

The case here -- rint(0.5) -- involves an input that can be represented
exactly, and an output that can be represented exactly (0.0). Neither nans,
infinities, nor denormalized numbers are involved. In this case I do expect
the correct answer, even with full floating point operations that ignore
nans, infinities, denormalized numbers, or that re-associate etc.

-erik

PS:

I think that

rint(x) = x + copysign(M,x) - copysign(M,x)

where M is a magic number, and where the addition and subtraction cannot be
optimized. I believe M=2^52. This should work fine at least for "reasonably
small" numbers.

-- 
Erik Schnetter <schnetter at cct.lsu.edu>
http://www.perimeterinstitute.ca/personal/eschnetter/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130704/baf6fb07/attachment.html>

----- Original Message -----
> 
> On Fri, Jun 21, 2013 at 5:11 PM, Erik Schnetter <
> schnetter at cct.lsu.edu > wrote:
> 
> 
> 
> 
> 
> 
> On Fri, Jun 21, 2013 at 7:54 AM, David Tweed < david.tweed at arm.com
>
> wrote:
> 
> 
> 
> 
> 
> 
> | LLVM does not currently have special lowering handling for round(),
> | and
> I'll propose a patch to add that, but the larger question is this:
> should
> fast-math change the tie-breaking behavior of
> | rint/nearbyint/round, etc. and, if so, should we make a specific
> | effort to
> have all backends provide the same guarantee (or lack of a guarantee)
> in
> this regard?
> 
> I don't know, primarily because I've never really been involved in
> anything
> where I've cared about using exotic rounding modes. But in general
> I'm of
> the opinion that -fast-math is the "nuclear option" that's
allowed to
> do
> lots of things which may well invoke backend specific behaviour.
> (That's
> also why I think that most FP transformations shouldn't be
"only"
> guarded by
> fast-math but a more precise option.)
> 
> 
> The functions rint and round and standard libm functions commonly
> used to round floating point values to integers. Both round to the
> nearest integer, but break ties differently -- rint uses IEEE tie
> breaking (towards even), round uses mathematical tie breaking (away
> from zero).
> 
> 
> The question here is: Is this optimization worthwhile, or would it
> surprise too many people? Depending on this, it should either be
> disallowed, or possibly implemented for other back-ends as well.
> 
> 
> After some consideration, I have come to the conclusion that this
> optimization (changing rint to round) is not worthwhile. There are
> some floating point operations that can provide an exact result, and
> not obtaining this exact result is surprising. For example, I would
> expect that adding/multiplying two small integers gives the exact
> result, or that fmin/fmax give the correct result if no nans are
> involved, or that comparisons yield the correct answer (again in the
> absence of nans, denormalized numbers etc.).
> 
> 
> The case here -- rint(0.5) -- involves an input that can be
> represented exactly, and an output that can be represented exactly
> (0.0). Neither nans, infinities, nor denormalized numbers are
> involved. In this case I do expect the correct answer, even with
> full floating point operations that ignore nans, infinities,
> denormalized numbers, or that re-associate etc.
I've been thinking about this for some time as well, and I've come to
the same conclusion. I'll be updating the PPC backend accordingly in the
near future. frin should really map to round() and not rint(), and we should
leave it at that.

Thanks again,
Hal
> 
> 
> -erik
> 
> 
> PS:
> 
> 
> I think that
> 
> 
> rint(x) = x + copysign(M,x) - copysign(M,x)
> 
> 
> where M is a magic number, and where the addition and subtraction
> cannot be optimized. I believe M=2^52. This should work fine at
> least for "reasonably small" numbers.
> 
> --
> Erik Schnetter < schnetter at cct.lsu.edu >
> http://www.perimeterinstitute.ca/personal/eschnetter/
-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory