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

[Jeff Hammond]

>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