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

[Chris Tetreault via llvm-dev]

The problem is that math code is often templated, so `template <typename T>  MyMatrixT<T> safeMul(const MyMatrixT<T> & lhs …` is going to be in a header.

Regardless, my position isn’t “there is no NaN”. My position is “you cannot count on operations on NaN working”. Just like sometimes you can dereference a pointer after it is free’d, but you should not count on this working. If the compiler I’m using emits a call to a library function instead of providing a macro, and this results in isnan actually computing if x is NaN, then so be it. But if the compiler provides a macro that evaluates to false under fast-math, then the two loops in safeMul can be optimized. Either way, as a developer, I know that I turned on fast-math, and I write code accordingly.

I think working around these sorts of issues is something that C and C++ developers are used to. These sorts of “inconsistent” between compilers behaviors is something we accept because we know it comes with improved performance. In this case, the fix is easy, so I don’t think this corner case is worth supporting. Especially when the fix is also just one line:

```
#define myIsNan(x) (reinterpret_cast<uint32_t>(x) == THE_BIT_PATTERN_OF_MY_SENTINEL_NAN)
```

I would probably call the macro something else like `shouldProcessElement`.

Thanks,
   Chris Tetreault

From: Serge Pavlov <sepavloff at gmail.com>
Sent: Friday, September 10, 2021 11:26 AM
To: Chris Tetreault <ctetreau at quicinc.com>
Cc: Richard Smith <richard at metafoo.co.uk>; llvm-dev at lists.llvm.org; cfe-dev at lists.llvm.org
Subject: Re: [llvm-dev] [cfe-dev] Should isnan be optimized out in fast-math mode?


WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
It should not be done in headers of course. Redefinition of this macro in the source file which is compiled with -ffinite-math-only is free from the described drawbacks. Besides, the macro `isnan` is defined by libc, not compiler and IIRC it is defined as macro to allow such manipulations.

Influence of libc on behavior of `isnan` in -ffinite-math-only is also an argument against "there are no NaNs". It causes inconsistency in the behavior. Libc can provide its own implementation, which does not rely on compiler `__builtin_isnan` and user code that uses `isnan` would work. But at some point configuration script changes or libc changed the macro and your code works wrong, as it happened after commit 767eadd78 in llvm libcxx project. Keeping `isnan` would make changes in libc less harmful.

Thanks,
--Serge

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210910/b322d7c1/attachment.html>