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

[Chris Tetreault via llvm-dev]

I don’t know if that check against infinity is UB, but the way I read the docs this code is not safe. If we had a pragma to control fast-math, then it would be easy to fix this.

From: Jorg Brown <jorg.brown at gmail.com>
Sent: Monday, September 20, 2021 11:29 AM
To: Chris Tetreault <ctetreau at quicinc.com>
Cc: Serge Pavlov <sepavloff at gmail.com>; LLVM Developers <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.
On Wed, Sep 8, 2021 at 11:04 AM Chris Tetreault via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
Of course, this all sounds fine and well, but the reality is that people don't read docs and don't make good life choices. They turn on fast math because they want it to reduce `x * 0` to `0`, and are surprised when their NaN handling code fails. This is unfortunate, but I don't think we should reduce the effectiveness of fast-math because of this human issue. Other flags exist for these users, and when they complain they should be told about them. Really this is an issue of poor developer discipline, and if we really want to solve this, perhaps some sort of "fast math sanitizer" can be created. It can statically analyze code and complain when it sees things like `if (isnan(foo))` not guarded by `__FAST_MATH__` with fast math enabled. Or, maybe the compiler can just issue a warning unconditionally in this case.

A "fast math sanitizer" sounds like a GREAT idea.

Also, I'd say that if -ffast-math is on, and -fsanitize=undefined, then the UB detection should already be doing this.

One caveat, though.  Suppose there is code like this:

if (d == std::numeric_limits<double>::infinity()) {

Does the comparison against infinity count as UB, since the compiler is allowed to assume there are no infinite fp values?  I hope not, or an optimization I'm about to check in will have to be reverted.

-- Jorg

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