<div dir="ltr">At least Fortran users have the same problem and have to use similar kludges: <a href="https://stackoverflow.com/questions/15944614/is-it-possible-to-make-isnan-work-in-gfortran-o3-ffast-math">https://stackoverflow.com/questions/15944614/is-it-possible-to-make-isnan-work-in-gfortran-o3-ffast-math</a>.<div><br></div><div>Rust has experimental fast-math intrinsics (<a href="https://doc.rust-lang.org/core/intrinsics/fn.fadd_fast.html">https://doc.rust-lang.org/core/intrinsics/fn.fadd_fast.html</a>). Their implementation must suffer from this optimization. Users report that using -fast-math gives 20% improvement (<a href="https://github.com/rust-lang/rust/issues/21690#issuecomment-307244726">https://github.com/rust-lang/rust/issues/21690#issuecomment-307244726</a>) but wrong results due to "some strange things (e.g., NaN checks always return false)".</div><div><br></div><div>This is one more reason for not removing `isnan` at least on llvm level.</div><div><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Thanks,<br>--Serge<br></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 16, 2021 at 7:06 PM Aaron Ballman <<a href="mailto:aaron@aaronballman.com">aaron@aaronballman.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, Sep 16, 2021 at 1:37 AM Serge Pavlov via cfe-dev<br>
<<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br>
><br>
> Let me make some summary. I omit references for brevity, they are spread in the thread.<br>
><br>
> Treatment of `isnan` with `-ffinite-math-only` has issues:<br>
> - There are many users' complaints and disagreement expressed in GCC bug tracker and forums about the treatment.<br>
> - There are legitimate use cases when `isnan` needs to be called in `-ffinite-math-only` mode.<br>
> - Users have to invent workarounds to get functionality of `isnan`, which results in portability and performance loss.<br>
> - There is inconsistency with the behavior of libc, which always does a real check, and the compiler, which omits it.<br>
> Preserving `isnan` in the code would solve all of them.<br>
><br>
> What is the risk?<br>
><br>
> `-ffinite-math-only` is an optimization option, so preserving `isnan` cannot break the behavior of correct programs. The only possible negative impact is some loss of performance. It is unlikely that a real program spends so much time in `isnan` calls that it has noticeable effect, but if it does, a user can conditionally redefine `isnan` macro.<br>
><br>
> Preserving `isnan` in `-ffinite-math-only` mode is safe and makes the compiler more reliable and user-friendly.<br>
<br>
FWIW, I personally come down on the side of *not* removing the call to<br>
isnan() that the user explicitly wrote. It's not beyond belief that a<br>
C API is called from another language that can generate a NaN, and a<br>
user who has enabled finite math only may still wish to guard against<br>
those cross-module cases passing in a NAN that they know their TU<br>
can't properly handle.<br>
<br>
~Aaron<br>
<br>
><br>
> Thanks,<br>
> --Serge<br>
> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div>