<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 2, 2021 at 4:00 PM James Y Knight <<a href="mailto:jyknight@google.com">jyknight@google.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 dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 2, 2021 at 3:07 PM Sanjay Patel via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 2, 2021 at 2:34 PM Serge Pavlov <<a href="mailto:sepavloff@gmail.com" target="_blank">sepavloff@gmail.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>Optimization is not the motivation for this intrinsic. If FP exceptions are ignored, unordered comparison can be used to implement `isnan`. If not, we need to make the test without affecting FP exceptions. Without this intrinsic there is no way to represent such a test. <br></div></div></div></blockquote><div><br></div><div>Here's a way to represent such a test without an intrinsic:</div><div>declare i1 @isnan(double)</div><div>...<br></div><div>%r = call i1 isnan(double x) #1</div><div>...</div><div>attributes #1 = { nounwind }</div><div></div></div></div></blockquote><div><br></div><div>No -- there is no "isnan" standard library call. C "isnan" is a macro which expands to whatever each libc desires. There is effectively no standardization as to what library function -- if any -- they actually end up calling. Therefore, the compiler's __builtin_isnan (and friends) cannot reasonably rely on generating library calls for these.</div></div></div></blockquote><div><br></div><div>Hmm...so the Apple clang "@__isnan" is a hack that we can't use? It seems to be there specifically for the FMF-based reason that was mentioned earlier as motivation for intrinsic isnan. Ie, it only seems to appear when 'nnan' would otherwise zap the corresponding 'fcmp uno'.</div><div> <br></div></div></div>