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

Jorg Brown via llvm-dev llvm-dev at lists.llvm.org
Mon Sep 20 11:29:11 PDT 2021


On Wed, Sep 8, 2021 at 11:04 AM Chris Tetreault via llvm-dev <
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/e3487714/attachment.html>


More information about the llvm-dev mailing list