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

[Dimitry Andric via llvm-dev]

> On 16 Sep 2021, at 20:18, Arthur O'Dwyer via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> 
> On Thu, Sep 16, 2021 at 1:31 PM Serge Pavlov <sepavloff at gmail.com <mailto:sepavloff at gmail.com>> wrote:
> On Tue, Sep 14, 2021 at 12:50 AM Serge Pavlov <sepavloff at gmail.com <mailto:sepavloff at gmail.com>> wrote:
> On Mon, Sep 13, 2021 at 11:46 PM Chris Tetreault <ctetreau at quicinc.com <mailto:ctetreau at quicinc.com>> wrote:
> … is guaranteed to work, and I read that fast-math enables the compiler to reason about constructs like `x + 0` being equal to `x`, then I’m going to be very confused when:
> You are right, this was a bad idea. Compiler may optimize out `isnan` but only when it deduces that the value cannot be NaN, but not due to the user's promise. It is especially important for `isinf`. Addition of two finite values may produce infinity and there is no universal way to predict it. It is probably not an issue for types like float or double, but ML cores use halfs or even minifloats, where overflow is much more probable. If in the code:
> ```
> float r = a + b;
> if (isinf(r)) {...
> ```
> `isinf` were optimized out just because -ffinite-math-only is in effect, the user cannot check if overflow did not occur.
> 
> Rules proposed by Richard are also formulated using arguments, not results. Now there is no intention to optimize such a case.
> 
> Infinity (HUGE_VAL) is already not NaN, so this example doesn't have anything to do with the NaN cases being discussed.

Well, there's https://bugs.llvm.org/show_bug.cgi?id=51775 <https://bugs.llvm.org/show_bug.cgi?id=51775>, "-ffast-math breaks strtod() due to "== HUGE_VAL" considered impossible"... :-)

-Dimitry


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210916/01240ef6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 223 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210916/01240ef6/attachment.sig>