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

[Hal Finkel]

----- Original Message -----
> 
> On Wed, Jun 19, 2013 at 1:20 PM, Hal Finkel < hfinkel at anl.gov >
> wrote:
> 
> 
> 
> 
> 
> 
> ----- Original Message -----
> > 
> > On Wed, Jun 19, 2013 at 12:48 PM, Hal Finkel < hfinkel at anl.gov >
> > wrote:
> > 
> > 
> > 
> > 
> > 
> > ----- Original Message -----
> > > 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:
> > 
> > Yes, Clang also defines __FAST_MATH__ -- however, I think that if a
> > user is forced to manually implement rint() then that is not a good
> > outcome.
> > 
> > 
> > 
> > I am not a user in this sense... I am developing a library that
> > provides a portable C++ interface to vector types.
> 
> You are a user of the compiler ;) -- Regardless, your opinion counts.
> 
> 
> > 
> > 
> > That is, this library <
> > https://bitbucket.org/eschnett/vecmathlib/wiki/Home > provides e.g.
> > a function
> > 
> > 
> > double4 rint(double4)
> > 
> > 
> > where "double4" is implemented as QPX vector on the BG/Q. The
> > question is now whether rint can be converted to round or not.
> 
> As far as I know, the QPX instruction does implement the
> round-to-even semantics (as does the corresponding Altivec
> instruction), it is just the scalar version that does not.
> 
> 
> 
> I think not. For QPX, the IBM compiler documentation for vec_round
> specifies it as round, not rint, and that's also what I found. For
> Altivec and VSX, vec_round is indeed rint.

Indeed you're correct. I misread the manual :(

> 
> 
> By the, way, I just found this for IBM's compiler documentation:
> "Note: This function might not follow the strict operation
> definition of the resolution of a tie during a round when you
> specify the -qstrict=nooperationprecision compiler option."

Interesting.

 -Hal

> 
> 
> -erik
> 
> 
> 
> -Hal
> 
> 
> 
> > 
> > 
> > -erik
> > 
> > 
> > 
> > 
> > 
> > -Hal
> > 
> > 
> > 
> > > 
> > > #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
> > > 
> > 
> > 
> > 
> > --
> > Hal Finkel
> > Assistant Computational Scientist
> > Leadership Computing Facility
> > Argonne National Laboratory
> > 
> > 
> > 
> > 
> > --
> > 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-bgq-discuss mailing list
> llvm-bgq-discuss at lists.alcf.anl.gov
> https://lists.alcf.anl.gov/mailman/listinfo/llvm-bgq-discuss
> 
> 
> 
> 
> --
> Erik Schnetter < schnetter at cct.lsu.edu >
> http://www.perimeterinstitute.ca/personal/eschnetter/

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