<div dir="ltr"><div dir="ltr">On Tue, Sep 21, 2021 at 3:46 AM antlists via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I know I may be coming in at half cock, but what is the CORRECT <br>
MATHEMATICAL behaviour?</blockquote><div><br></div><div>I'll use your question to make a summary.</div><div><br></div><div> Now clang removes calls to `isnan` in -ffinite-math-only. The justification for such behavior comes from early GCC viewpoint (<a href="https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50724#c1">https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50724#c1</a>):</div><br>"With -ffinite-math-only you are telling that there are no NaNs"<br><br>On this assumption the removal of `isnan` is a perfectly valid optimization, it produces a program that behaves identically to the initial program, which contains `isnan`. For all valid input data it produces  the same output.<br><br>Actually the existence of NaNs cannot be ignored even if no operations on NaNs take place. There are several reasons for that, at least:<br>       - Users need  to check the input data, for example to assert, or to choose a slower but general path.<br>        - NaN can be used as a sentinel. In this case it is actually not a number but some distinguishable bit pattern.<br>       - NaNs can be produced by operations on "allowed" numbers. It is easier to demonstrate on infinities. The expression `x * y` may produce infinity when its operands are finite numbers and it is hard to reveal that without execution of the operation.<br>    - Code compiled with `-ffinite-math-only` may call functions from libraries or from other parts of the program, compiled without this flag. These functions may return infinities and NaNs. It is often impractical to check the arguments prior to the call to ensure the result would be finite. In some cases it is even impossible. In this case it is necessary to check if the result is finite.<br><br>The "correct behavior" depends on whether NaNs are allowed in the code compiled with -ffinite-math-only:<br>- if no, we have the current behavior,<br>- if yes, `isnan` cannot be optimized out.<br><br>The approach "-ffinite-math-only means there are no NaNs" is an abstraction that does not fit user needs. This problem is actually common. There are many user feedbacks, in GCC bug tracker:<br>   - <a href="https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50724">https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50724</a><br>   - <a href="https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84949">https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84949</a><br>as well as in forums:<br>    - <a href="https://stackoverflow.com/questions/38978951/can-ffast-math-be-safely-used-on-a-typical-project">https://stackoverflow.com/questions/38978951/can-ffast-math-be-safely-used-on-a-typical-project</a><br> - <a href="https://stackoverflow.com/questions/47703436/isnan-does-not-work-correctly-with-ofast-flags">https://stackoverflow.com/questions/47703436/isnan-does-not-work-correctly-with-ofast-flags</a><br>To support `isnan` with -ffinite-math-only users have to use kludges like emulating `isnan` with integer arithmetic, calling libs implementation or moving their own `isnan` implementation to separate translation units. All of them have drawbacks and bring loss in portability and performance.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">The proposal was to support the programming model, anticipated by many users. Advantages and risks were discussed in the thread previously.</div><div class="gmail_quote"><br></div><div class="gmail_quote">Thanks,</div><div class="gmail_quote">--Serge</div></div>