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

Erik Schnetter schnetter at cct.lsu.edu
Fri Jun 21 14:11:12 PDT 2013


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>


More information about the llvm-dev mailing list