<div dir="ltr">On Wed, Jun 19, 2013 at 1:20 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=""><div class="h5">----- Original Message -----<br>
><br>
> On Wed, Jun 19, 2013 at 12:48 PM, Hal Finkel < <a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a> ><br>
> wrote:<br>
><br>
><br>
><br>
><br>
><br>
> ----- 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<br>
> > 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>
> Yes, Clang also defines __FAST_MATH__ -- however, I think that if a<br>
> user is forced to manually implement rint() then that is not a good<br>
> outcome.<br>
><br>
><br>
><br>
> I am not a user in this sense... I am developing a library that<br>
> provides a portable C++ interface to vector types.<br>
<br>
</div></div>You are a user of the compiler ;) -- Regardless, your opinion counts.<br>
<div class="im"><br>
><br>
><br>
> That is, this library <<br>
> <a href="https://bitbucket.org/eschnett/vecmathlib/wiki/Home" target="_blank">https://bitbucket.org/eschnett/vecmathlib/wiki/Home</a> > provides e.g.<br>
> a function<br>
><br>
><br>
> double4 rint(double4)<br>
><br>
><br>
> where "double4" is implemented as QPX vector on the BG/Q. The<br>
> question is now whether rint can be converted to round or not.<br>
<br>
</div>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.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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."</div>
<div><br></div><div>-erik</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>
><br>
> -erik<br>
><br>
><br>
><br>
><br>
><br>
> -Hal<br>
><br>
><br>
><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<br>
> > >> > 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<br>
> > >> > 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<br>
> > >> than<br>
> > >> the libc<br>
> > >> function call. That having been said, I put this optimization<br>
> > >> in,<br>
> > >> and I can<br>
> > >> take it out again ;) [or make it require some other flag]. Is<br>
> > >> 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>
><br>
><br>
> --<br>
> Hal Finkel<br>
> Assistant Computational Scientist<br>
> Leadership Computing Facility<br>
> Argonne National Laboratory<br>
><br>
><br>
><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>
Hal Finkel<br>
Assistant Computational Scientist<br>
Leadership Computing Facility<br>
Argonne National Laboratory<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>
</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>