<div dir="ltr"><div><div><div><div>Yes, if %x is a NaN, we should expect that NaN is propagated. <br><br>I'm still not sure what to do here. We can take comfort in knowing that whatever we do is likely an improvement over the current situation though. :)<br></div>That's because the code in InstSimplify is inconsistent with the LangRef:<br><a href="http://llvm.org/docs/LangRef.html#undefined-values" target="_blank">http://llvm.org/docs/LangRef.h<wbr>tml#undefined-values</a> (UB for fdiv by 0?)<br></div>...and both of those are inconsistent with undef handling in SDAG.<br><br></div>Let me propose an alternate interpretation: <br><br>1. The meaning of snan as written in <span>IEEE754-2008 is: "<span><span>Signaling NaNs afford representations for uninitialized variables...</span></span>"<br>2. </span><span>That matches our intent with 'undef' here in IR as written in the LangRef: "unspecified
bit-pattern".<br>3. The current fdiv transform is actually correct (any SNaN UB/trapping commentary is irrelevant because we assume exceptions are off by default). <br><br>The undef operand represents an uninitialized variable, and the result of any FP op with that uninitialized variable is well-defined: it's another NaN which is just 'undef' in IR.<br></span></div><div><span><br></span></div><div><span><br></span></div><div><span><br></span><span></span></div><div><div><span></span><br><div><div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 28, 2018 at 11:43 AM, Kaylor, Andrew <span dir="ltr"><<a href="mailto:andrew.kaylor@intel.com" target="_blank">andrew.kaylor@intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div lang="EN-US">
<div class="m_-4918008932178653133m_4642868960215344090m_-8687162237574238509m_6296887673449776883gmail-m_-8004251218016727144WordSection1">
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)">I’m not sure the transformation happening with fdiv is correct. If we have “%y = fdiv float %x, undef” and %x is a NaN then the result will be NaN for any value
of the undef, right? So if I understand the undef rules correctly (never a certainty) then we can’t safely replace the expression with undef. We could, I think, replace it with “%y = %x” though. I think the same is true for fadd, fsub, fmul, and frem.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)">-Andy<u></u><u></u></span></p>
<p class="MsoNormal"><a name="m_-4918008932178653133_m_4642868960215344090_m_-8687162237574238509_m_6296887673449776883_m_-8004251218016727144__MailEndCompose"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></a></p>
<p class="MsoNormal"><br></p><div><div class="m_-4918008932178653133m_4642868960215344090m_-8687162237574238509m_6296887673449776883gmail-h5">
<div>
<div>
<div>
<p class="MsoNormal">%y = fadd float %x, undef<u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Can we simplify this? <br>
<br>
Currently in IR, we do nothing for fadd/fsub/fmul. For fdiv/frem, we propagate undef. The code comment for fdiv/frem says:<br>
"the undef could be a snan"<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">If that's correct, then shouldn't it be the same for fadd/fsub/fmul? But this can't be correct because we support targets that don't raise exceptions...and even targets that raise exceptions do not trap by default on snan?<u></u><u></u></p>
</div>
</div>
</div></div></div>
</div>
</blockquote></div><br></div></div></div></div></div></div></div></div>