<div dir="ltr">On Wed, Jun 19, 2013 at 1:15 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">----- Original Message -----<br>
><br>
> Actually, the Intel AVX instructions have a similar issue: rint() has<br>
> a fast instruction, but round() does not. On this architecture,<br>
> round() still does the "right thing", even with -ffast-math, both<br>
> with gcc and clang.<br>
><br>
><br>
> Actually, as I just see, gcc generates a short sequence of<br>
> instructions (five or so) to implement round() properly, whereas<br>
> clang calls _round.<br>
<br>
</div>LLVM only seems to have special handling of:<br>
FCEIL, FTRUNC, FRINT, FNEARBYINT, FFLOOR<br>
(as there is no FROUND and so round() will always give you the library call).<br>
<div class="im"><br>
><br>
><br>
> Given this, the behaviour on BGQ is indeed special. I would expect<br>
> clang to behave consistently -- to either apply this optimization<br>
> across the board, or nowhere. Do you want to raise the issue on the<br>
> llvm mailing list?<br>
<br>
</div>Unfortunately, this optimization (as are many low-level fast-math optimizations) is target-specific. As a result, I'm not sure that you'll even really get the cross-platform consistency that you'd like. That having been said, if this change is too strong, then we should back it out.<br>
</blockquote><div><br></div><div>Yes, it's target specific. Nevertheless, whether rint's tie-breaking can be influenced by __FAST_MATH__ should be a consensus decision. Either BGQ is over-zealous, or Intel is missing a possible optimisation, or llvm makes different speed/accuracy trade-offs on different architectures. And the latter would be bad for users.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Separately, Clang/LLVM should support backend specialization of round() -- and as you imply, the frin instruction does seem to implement the semantics of round() more than it implements that of rint() (or nearbyint()) [is that right?].<br>
</blockquote><div><br></div><div>Yes, frin seems to implement round.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I know that I discussed this at length with the IBM LLVM contributors, and I don't recall if I discussed this on the LLVM list, but we could certainly ask for opinions from a wider audience.<br>

<br>
Thanks again,<br>
Hal<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
><br>
><br>
> -erik<br>
><br>
><br>
><br>
><br>
><br>
> On Wed, Jun 19, 2013 at 11:52 AM, Jeff Hammond <<br>
> <a href="mailto:jhammond@alcf.anl.gov">jhammond@alcf.anl.gov</a> > wrote:<br>
><br>
><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>
> #ifdef __FAST_MATH__<br>
> slower_rounding_function_that_is_always_correct(stuff);<br>
> #else<br>
> rint(stuff);<br>
> #endif<br>
><br>
> Jeff<br>
><br>
><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>
><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>
> 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>
</div></div><div class="HOEnZb"><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>