<div dir="ltr"><div dir="ltr"><div>Thanks for making this clearer. So there's general consensus that we need an intrinsic to represent isnan()...<br></div><div>1. How many others like this do we need? (see the list that James provided a couple of mails earlier)</div><div>2. How do we introduce these and limit regressions? <a href="https://reviews.llvm.org/D104854" target="_blank">D104854</a> had clang produce isnan() for all modes simultaneously, but that leads to problems like: <span class="gmail-transaction-comment"><a href="https://llvm.org/PR51556" class="gmail-remarkup-link" target="_blank" rel="noreferrer">https://llvm.org/PR51556</a> . I suggest introducing these in LLVM only or in clang with strictFP modes only as a 1st step, so we're not causing perf regressions that require reverting large patches.<br></span></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 24, 2021 at 8:26 AM Kevin Neal <<a href="mailto:Kevin.Neal@sas.com">Kevin.Neal@sas.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div style="overflow-wrap: break-word;" lang="EN-US">
<div class="gmail-m_2614469788384614650WordSection1">
<p class="MsoNormal"><span style="font-family:"Courier New";color:rgb(68,84,106)">It probably doesn’t help that IEEE 754-2019 uses the word “signal” to mean, paraphrased, “set a bit in a status register and continue producing a result with no trap”, and that’s in
the default FP environment. So IEEE “signaling” is not Unix “signaling”.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New";color:rgb(68,84,106)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New";color:rgb(68,84,106)">Once one picks up on that distinction the IEEE 754 document reads a lot like Andy’s description of x86-64 behavior.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New";color:rgb(68,84,106)"><u></u> <u></u></span></p>
<div>
<div style="border-color:rgb(225,225,225) currentcolor currentcolor;border-style:solid none none;border-width:1pt medium medium;padding:3pt 0in 0in">
<p class="MsoNormal"><b>From:</b> Kaylor, Andrew <<a href="mailto:andrew.kaylor@intel.com" target="_blank">andrew.kaylor@intel.com</a>> <br>
<b>Sent:</b> Monday, August 23, 2021 6:31 PM<br>
<b>To:</b> Arthur O'Dwyer <<a href="mailto:arthur.j.odwyer@gmail.com" target="_blank">arthur.j.odwyer@gmail.com</a>>; Sanjay Patel <<a href="mailto:spatel@rotateright.com" target="_blank">spatel@rotateright.com</a>><br>
<b>Cc:</b> Kevin Neal <<a href="mailto:Kevin.Neal@sas.com" target="_blank">Kevin.Neal@sas.com</a>>; Wang, Pengfei <<a href="mailto:pengfei.wang@intel.com" target="_blank">pengfei.wang@intel.com</a>>; <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>; Clang Dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>><br>
<b>Subject:</b> RE: [cfe-dev] [llvm-dev] Intrinsic llvm::isnan<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<p><b><i><span style="font-size:12pt;font-family:"Arial",sans-serif;color:red">EXTERNAL</span></i></b><span style="font-size:12pt;font-family:"Arial",sans-serif;color:red">
</span><u></u><u></u></p>
<div>
<p class="MsoNormal">I think the confusion here has to do with what it means for the optimizer to assume that “floating-point exceptions will be masked”. What I’m about to say may be specific to the x86-64-based processor behavior because that’s the one I know,
but I think other architectures will have similar behavior but possibly with different terms?<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">If a floating point exception occurs in an operation and that exception is masked in the floating point control registers, the status bit for that exception will be set and nothing else will happen. If a floating point exception occurs
in an operation and that exception is NOT masked in the floating point control registers, an exception handler will be called.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">So, what the current documentation means to say is that the optimizer may assume that the status flags will not be read and that no exception handler will be called if a floating point exception occurs. Basically, it means that floating
point exceptions will be ignored in all ways.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">> It's still not clear to me if there's a benefit from having an intrinsic vs. one more exception mode ("none" or "off").<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">The key point to recognize here is that the metadata arguments to the constrained intrinsics are intended to describe assumptions that can or cannot be made. They are not intended to bring about the state that they describe. So, for example,
if the rounding mode argument is set to “fpround.tonearest” that means the optimizer can assume that the processor is set to use the “tonearest” rounding mode, but it does not enforce this. If we see this flag during ISel, we can select an instruction that
takes an explicit rounding mode argument and use the “tonearest” value for that argument, but we are also allowed to select an instruction that uses the rounding mode from the MXCSR register and assume that when this instruction is executed that rounding mode
will be “tonearest”.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">If you need an intrinsic that is guaranteed not to raise exceptions, that should be a distinct intrinsic from any similar intrinsic that may raise exceptions. See, for example, llvm.experimental.constrained.nearbyint and llvm.experimental.constrained.rint
which differ only in exception behavior.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">-Andy<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div style="border-color:rgb(225,225,225) currentcolor currentcolor;border-style:solid none none;border-width:1pt medium medium;padding:3pt 0in 0in">
<p class="MsoNormal"><b>From:</b> Arthur O'Dwyer <<a href="mailto:arthur.j.odwyer@gmail.com" target="_blank">arthur.j.odwyer@gmail.com</a>>
<br>
<b>Sent:</b> Monday, August 23, 2021 2:37 PM<br>
<b>To:</b> Sanjay Patel <<a href="mailto:spatel@rotateright.com" target="_blank">spatel@rotateright.com</a>><br>
<b>Cc:</b> Kaylor, Andrew <<a href="mailto:andrew.kaylor@intel.com" target="_blank">andrew.kaylor@intel.com</a>>; Kevin Neal <<a href="mailto:Kevin.Neal@sas.com" target="_blank">Kevin.Neal@sas.com</a>>; Wang, Pengfei <<a href="mailto:pengfei.wang@intel.com" target="_blank">pengfei.wang@intel.com</a>>;
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>; Clang Dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>><br>
<b>Subject:</b> Re: [cfe-dev] [llvm-dev] Intrinsic llvm::isnan<u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Mon, Aug 23, 2021 at 3:42 PM Sanjay Patel via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<u></u><u></u></p>
</div>
<div>
<blockquote style="border-color:currentcolor currentcolor currentcolor rgb(204,204,204);border-style:none none none solid;border-width:medium medium medium 1pt;padding:0in 0in 0in 6pt;margin:5pt 0in 5pt 4.8pt">
<div>
<div>
<p class="MsoNormal">Ok, does this edit to the LangRef make sense for the definition of "ignore":<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">"optimization passes may assume that the exception status flags will not be read and that floating-point exceptions **will** be masked" --><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">"optimization passes may assume that the exception status flags will not be read and that floating-point exceptions **may** be masked"<u></u><u></u></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I haven't been following the technical details, but in terms of the English documentation, it makes no sense to say that someone "may assume that [X]
<b><i>may</i></b> happen." Either [X] always happens, in which case optimization passes may safely assume that it happens; or [X] never happens, in which case optimization passes may safely assume that it does not happen; or else [X] sometimes happens and sometimes
doesn't, in which case optimizations passes <b><i>must not assume anything</i></b> about [X].<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">So you might say: "optimization passes may assume that the exception status flags will not be read. Floating-point exceptions might or might not be masked, depending on [____]" (and then mention the relevant variable, such as "instruction
set" or "optimization level" or whatever).<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">HTH,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Arthur<u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote></div></div>