[Llvm-bgq-discuss] rint() with -ffast-math

[Hal Finkel]

----- Original Message -----
> 
> By the way (and indicating that I recently spent way too much time
> learning about IEEE rounding, and thinking about how to implement
> this efficiently):
> 
> 
> double round(double x) { return trunc(x + copysign(0.5, x)); }
> 
> 
> is correct and quite efficient if trunc is efficient (ignoring nans,
> infs, etc.). If you have an efficient floor instead of trunc, then
> you can also use
> 
> 
> double round(double x) { return copysign(floor(fabs(x)+0.5), x); }
> 
> 
> 
> which probably requires one more instruction because of the fabs.

Thanks! This seems quite useful.

 -Hal

> 
> 
> -erik
> 
> 
> 
> 
> 
> On Wed, Jun 19, 2013 at 12:03 PM, Erik Schnetter <
> schnetter at cct.lsu.edu > wrote:
> 
> 
> 
> Actually, the Intel AVX instructions have a similar issue: rint() has
> a fast instruction, but round() does not. On this architecture,
> round() still does the "right thing", even with -ffast-math, both
> with gcc and clang.
> 
> 
> Actually, as I just see, gcc generates a short sequence of
> instructions (five or so) to implement round() properly, whereas
> clang calls _round.
> 
> 
> Given this, the behaviour on BGQ is indeed special. I would expect
> clang to behave consistently -- to either apply this optimization
> across the board, or nowhere. Do you want to raise the issue on the
> llvm mailing list?
> 
> 
> 
> -erik
> 
> 
> 
> 
> 
> 
> 
> On Wed, Jun 19, 2013 at 11:52 AM, Jeff Hammond <
> jhammond at alcf.anl.gov > wrote:
> 
> 
> From
> http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Optimize-Options.html :
> ===========================================================================
> -ffast-math
> 
> Sets -fno-math-errno, -funsafe-math-optimizations,
> -fno-trapping-math,
> -ffinite-math-only, -fno-rounding-math, -fno-signaling-nans and
> fcx-limited-range.
> 
> This option causes the preprocessor macro __FAST_MATH__ to be
> defined.
> 
> This option should never be turned on by any -O option since it can
> result in incorrect output for programs which depend on an exact
> implementation of IEEE or ISO rules/specifications for math
> functions.
> ===========================================================================
> 
> Based upon this, I would not count on accurate results when fast-math
> is defined unless explicitly verified.
> 
> Assuming LLVM behaves like GCC and defines __FAST_MATH__, you could
> also do this:
> 
> #ifdef __FAST_MATH__
> slower_rounding_function_that_is_always_correct(stuff);
> #else
> rint(stuff);
> #endif
> 
> Jeff
> 
> 
> 
> On Wed, Jun 19, 2013 at 10:48 AM, Erik Schnetter <
> schnetter at cct.lsu.edu > wrote:
> > On Wed, Jun 19, 2013 at 11:12 AM, Hal Finkel < hfinkel at anl.gov >
> > wrote:
> >> 
> >> ----- Original Message -----
> >> > 
> >> > 
> >> > 
> >> > The function rint() is supposed to round to the nearest integer,
> >> > breaking ties to even. With -ffast-math, it breaks ties away
> >> > from
> >> > zero. That is, in corner cases the result is incorrectly
> >> > rounded.
> >> > 
> >> > 
> >> > Is this intended? This (BGQ with Clang) is the first system that
> >> > does
> >> > so. (I understand why one would do this given the machine
> >> > instructions available.)
> >> 
> >> Yes, this is the intended behavior (and LLVM will currently do
> >> this on all
> >> PPC systems). It is a function of the (odd) way in which the PPC
> >> frin
> >> instruction is defined. The upside is that it is much faster than
> >> the libc
> >> function call. That having been said, I put this optimization in,
> >> and I can
> >> take it out again ;) [or make it require some other flag]. Is the
> >> behavior
> >> too different for you?
> > 
> > 
> > I can live with this optimization, I just want to know where
> > -ffast-math has
> > its boundaries...
> > 
> > -erik
> > 
> > --
> > Erik Schnetter < schnetter at cct.lsu.edu >
> > http://www.perimeterinstitute.ca/personal/eschnetter/
> > 
> 
> 
> > _______________________________________________
> > llvm-bgq-discuss mailing list
> > llvm-bgq-discuss at lists.alcf.anl.gov
> > https://lists.alcf.anl.gov/mailman/listinfo/llvm-bgq-discuss
> > 
> 
> 
> 
> --
> Jeff Hammond
> Argonne Leadership Computing Facility
> University of Chicago Computation Institute
> jhammond at alcf.anl.gov / (630) 252-5381
> http://www.linkedin.com/in/jeffhammond
> https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond
> ALCF docs: http://www.alcf.anl.gov/user-guides
> 
> 
> 
> 
> --
> Erik Schnetter < schnetter at cct.lsu.edu >
> http://www.perimeterinstitute.ca/personal/eschnetter/
> 
> 
> 
> --
> Erik Schnetter < schnetter at cct.lsu.edu >
> http://www.perimeterinstitute.ca/personal/eschnetter/

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