[LLVMdev] round() vs. rint()/nearbyint() with fast-math

[Hal Finkel]

----- Original Message -----
> 
> 
> ----- 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.

The PowerPC backend has been modified in r187960 to map round() -> frin (and remove the nearbyint() and rint() fast-math mappings).

Thanks again,
Hal

> 
> 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
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory