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

[Joerg Sonnenberger via llvm-dev]

On Fri, Sep 10, 2021 at 04:28:31PM +0000, Chris Tetreault via cfe-dev wrote:
> I’m not super knowledgeable on the actual implementation of floating
> point math in clang, but on the surface this seems fine. My position
> is that we should provide no guarantees as to the behavior of code with
> NaN or infinity if fast-math is enabled. We can go with this behavior,
> but we shouldn’t tell users that they can rely on this behavior. Clang
> should have maximal freedom to optimize floating point math with
> fast-math, and any constraint we place potentially results in missed
> opportunities. Similarly we should feel free to change this
> implementation in the future, the goal not being stability for users
> who chose to rely on our implementation details. If users value
> reproducibility, they should not be using fast math.

Without trying to be too harsh, this is the bad justification GCC has
used for years for exploiting all kinds of UB and implementation-defined
behavior in the name of performance. As has been shown over and over
again, the breakage is rarely matched by equivalent performance gains.
So once more, do we even have proof that significant code exists where
isnan and friends are used in a performance critical code path? I would
find that quite surprising and more an argument for throwing a compile
error...

Joerg