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

[Aaron Ballman via llvm-dev]

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