[cfe-dev] [llvm-dev] Should isnan be optimized out in fast-math mode?

Serge Pavlov via cfe-dev cfe-dev at lists.llvm.org
Thu Sep 16 06:47:36 PDT 2021

At least Fortran users have the same problem and have to use similar

Rust has experimental fast-math intrinsics (
https://doc.rust-lang.org/core/intrinsics/fn.fadd_fast.html). Their
implementation must suffer from this optimization. Users report that using
-fast-math gives 20% improvement (
https://github.com/rust-lang/rust/issues/21690#issuecomment-307244726) but
wrong results due to "some strange things (e.g., NaN checks always return

This is one more reason for not removing `isnan` at least on llvm level.


On Thu, Sep 16, 2021 at 7:06 PM Aaron Ballman <aaron at aaronballman.com>

> On Thu, Sep 16, 2021 at 1:37 AM Serge Pavlov via cfe-dev
> <cfe-dev at lists.llvm.org> wrote:
> >
> > Let me make some summary. I omit references for brevity, they are spread
> in the thread.
> >
> > Treatment of `isnan` with `-ffinite-math-only` has issues:
> > - There are many users' complaints and disagreement expressed in GCC bug
> tracker and forums about the treatment.
> > - There are legitimate use cases when `isnan` needs to be called in
> `-ffinite-math-only` mode.
> > - Users have to invent workarounds to get functionality of `isnan`,
> which results in portability and performance loss.
> > - There is inconsistency with the behavior of libc, which always does a
> real check, and the compiler, which omits it.
> > Preserving `isnan` in the code would solve all of them.
> >
> > What is the risk?
> >
> > `-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.
> >
> > Preserving `isnan` in `-ffinite-math-only` mode is safe and makes the
> compiler more reliable and user-friendly.
> FWIW, I personally come down on the side of *not* removing the call to
> isnan() that the user explicitly wrote. It's not beyond belief that a
> C API is called from another language that can generate a NaN, and a
> user who has enabled finite math only may still wish to guard against
> those cross-module cases passing in a NAN that they know their TU
> can't properly handle.
> ~Aaron
> >
> > Thanks,
> > --Serge
> > _______________________________________________
> > cfe-dev mailing list
> > cfe-dev at lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20210916/333dd10a/attachment-0001.html>

More information about the cfe-dev mailing list