<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">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><br></div><div>Probably the best you could say is that we don't support __builtin_isnan/etc in strict-fp mode. But that's not a good solution, either.</div><div><br></div></div></div>