<div dir="ltr">On Wed, Jun 19, 2013 at 12:48 PM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">----- Original Message -----<br>
> From<br>
> <a href="http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Optimize-Options.html" target="_blank">http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Optimize-Options.html</a>:<br>
> ===========================================================================<br>
> -ffast-math<br>
><br>
> Sets -fno-math-errno, -funsafe-math-optimizations,<br>
> -fno-trapping-math,<br>
> -ffinite-math-only, -fno-rounding-math, -fno-signaling-nans and<br>
> fcx-limited-range.<br>
><br>
> This option causes the preprocessor macro __FAST_MATH__ to be<br>
> defined.<br>
><br>
> This option should never be turned on by any -O option since it can<br>
> result in incorrect output for programs which depend on an exact<br>
> implementation of IEEE or ISO rules/specifications for math<br>
> functions.<br>
> ===========================================================================<br>
><br>
> Based upon this, I would not count on accurate results when fast-math<br>
> is defined unless explicitly verified.<br>
><br>
> Assuming LLVM behaves like GCC and defines __FAST_MATH__, you could<br>
> also do this:<br>
<br>
</div>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.<br></blockquote><div><br></div><div>I am not a user in this sense... I am developing a library that provides a portable C++ interface to vector types.</div>
<div><br></div><div>That is, this library <<a href="https://bitbucket.org/eschnett/vecmathlib/wiki/Home">https://bitbucket.org/eschnett/vecmathlib/wiki/Home</a>> provides e.g. a function</div><div><br></div><div>double4 rint(double4)</div>
<div><br></div><div>where "double4" is implemented as QPX vector on the BG/Q. The question is now whether rint can be converted to round or not.</div><div><br></div><div>-erik</div><div><br></div><div><br></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><font color="#888888"> -Hal<br>
</font></span><div class=""><div class="h5"><br>
><br>
> #ifdef __FAST_MATH__<br>
>   slower_rounding_function_that_is_always_correct(stuff);<br>
> #else<br>
>   rint(stuff);<br>
> #endif<br>
><br>
> Jeff<br>
><br>
> On Wed, Jun 19, 2013 at 10:48 AM, Erik Schnetter<br>
> <<a href="mailto:schnetter@cct.lsu.edu">schnetter@cct.lsu.edu</a>> wrote:<br>
> > On Wed, Jun 19, 2013 at 11:12 AM, Hal Finkel <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>><br>
> > wrote:<br>
> >><br>
> >> ----- Original Message -----<br>
> >> ><br>
> >> ><br>
> >> ><br>
> >> > The function rint() is supposed to round to the nearest integer,<br>
> >> > breaking ties to even. With -ffast-math, it breaks ties away<br>
> >> > from<br>
> >> > zero. That is, in corner cases the result is incorrectly<br>
> >> > rounded.<br>
> >> ><br>
> >> ><br>
> >> > Is this intended? This (BGQ with Clang) is the first system that<br>
> >> > does<br>
> >> > so. (I understand why one would do this given the machine<br>
> >> > instructions available.)<br>
> >><br>
> >> Yes, this is the intended behavior (and LLVM will currently do<br>
> >> this on all<br>
> >> PPC systems). It is a function of the (odd) way in which the PPC<br>
> >> frin<br>
> >> instruction is defined. The upside is that it is much faster than<br>
> >> the libc<br>
> >> function call. That having been said, I put this optimization in,<br>
> >> and I can<br>
> >> take it out again ;) [or make it require some other flag]. Is the<br>
> >> behavior<br>
> >> too different for you?<br>
> ><br>
> ><br>
> > I can live with this optimization, I just want to know where<br>
> > -ffast-math has<br>
> > its boundaries...<br>
> ><br>
> > -erik<br>
> ><br>
> > --<br>
> > Erik Schnetter <<a href="mailto:schnetter@cct.lsu.edu">schnetter@cct.lsu.edu</a>><br>
> > <a href="http://www.perimeterinstitute.ca/personal/eschnetter/" target="_blank">http://www.perimeterinstitute.ca/personal/eschnetter/</a><br>
> ><br>
> > _______________________________________________<br>
> > llvm-bgq-discuss mailing list<br>
> > <a href="mailto:llvm-bgq-discuss@lists.alcf.anl.gov">llvm-bgq-discuss@lists.alcf.anl.gov</a><br>
> > <a href="https://lists.alcf.anl.gov/mailman/listinfo/llvm-bgq-discuss" target="_blank">https://lists.alcf.anl.gov/mailman/listinfo/llvm-bgq-discuss</a><br>
> ><br>
><br>
><br>
><br>
> --<br>
> Jeff Hammond<br>
> Argonne Leadership Computing Facility<br>
> University of Chicago Computation Institute<br>
> <a href="mailto:jhammond@alcf.anl.gov">jhammond@alcf.anl.gov</a> / <a href="tel:%28630%29%20252-5381" value="+16302525381">(630) 252-5381</a><br>
> <a href="http://www.linkedin.com/in/jeffhammond" target="_blank">http://www.linkedin.com/in/jeffhammond</a><br>
> <a href="https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond" target="_blank">https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond</a><br>
> ALCF docs: <a href="http://www.alcf.anl.gov/user-guides" target="_blank">http://www.alcf.anl.gov/user-guides</a><br>
><br>
<br>
</div></div><div class=""><div class="h5">--<br>
Hal Finkel<br>
Assistant Computational Scientist<br>
Leadership Computing Facility<br>
Argonne National Laboratory<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Erik Schnetter <<a href="mailto:schnetter@cct.lsu.edu" target="_blank">schnetter@cct.lsu.edu</a>><br><a href="http://www.perimeterinstitute.ca/personal/eschnetter/" target="_blank">http://www.perimeterinstitute.ca/personal/eschnetter/</a>
</div></div>