<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">I think you are not adequately summing up the risks of your approach; there are three other issues I see.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">First, redefining `isnan` as a macro is expressly undefined behavior in C (see section 7.1.3, clauses 2 and 3—it’s undefined behavior to define a macro as a same name as reserved identifier in a standard library header). Conditionally redefining
an `isnan` macro is therefore not a permissible solution.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The second thing that has been repeatedly brought up that is missing is the fact that `isnan` may still be inconsistently optimized out. `isnan(x)` would only be retained in the program if the compiler cannot deduce that `x` is the result
of a nnan arithmetic operation. If it can deduce that—the simplest case being the somewhat questionable `isnan(x + 0)` example, but it’s also possible that, e.g., you’re calling `isnan(sum)` on the result of a summation, which would be the result of an arithmetic
expression post-mem2reg/SROA—then the compiler would still elide it. It could be that this is less surprising to users than unconditionally optimizing array `isnan(x)`, but it should still be admitted that there is a potential for surprise here.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">A final point is that the potential optimization benefits of eliding `isnan` are not limited to the cost of running the function itself (which are likely to be negligible), but also include the benefits of deleting any subsequent code that
is attempting to handle NaN values, which may be fairly large blocks. A salient example is complex multiplication and division, where the actual expansion of the multiplication and division code itself is dwarfed by the recalculation code if the result turns
out to be a NaN.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> llvm-dev <llvm-dev-bounces@lists.llvm.org> <b>On Behalf Of
</b>Serge Pavlov via llvm-dev<br>
<b>Sent:</b> Thursday, September 16, 2021 1:37<br>
<b>To:</b> Chris Tetreault <ctetreau@quicinc.com><br>
<b>Cc:</b> Arthur O'Dwyer <arthur.j.odwyer@gmail.com>; llvm-dev@lists.llvm.org; cfe-dev@lists.llvm.org<br>
<b>Subject:</b> Re: [llvm-dev] [cfe-dev] Should isnan be optimized out in fast-math mode?<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">Let me make some summary. I omit references for brevity, they are spread in the thread.<br>
<br>
Treatment of `isnan` with `-ffinite-math-only` has issues:<br>
- There are many users' complaints and disagreement expressed in GCC bug tracker and forums about the treatment.<br>
- There are legitimate use cases when `isnan` needs to be called in `-ffinite-math-only` mode.<br>
- Users have to invent workarounds to get functionality of `isnan`, which results in portability and performance loss.<br>
- There is inconsistency with the behavior of libc, which always does a real check, and the compiler, which omits it.<br>
Preserving `isnan` in the code would solve all of them.<br>
<br>
What is the risk?<br>
<br>
`-ffinite-math-only` is an optimization option, so preserving `isnan` cannot break the behavior of correct programs. The only possible negative impact is some loss of performance. It is unlikely that a real program spends so much time in `isnan` calls that
it has noticeable effect, but if it does, a user can conditionally redefine `isnan` macro.<br>
<br>
Preserving `isnan` in `-ffinite-math-only` mode is safe and makes the compiler more reliable and user-friendly.
<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Thanks,<br>
--Serge<o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>