[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