<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 12, 2014 at 3:04 PM, Owen Anderson <span dir="ltr"><<a href="mailto:resistor@mac.com" target="_blank">resistor@mac.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 style="word-wrap:break-word"><div><div class="h5"><br><div><blockquote type="cite"><div>On Sep 12, 2014, at 2:24 PM, Owen Anderson <<a href="mailto:resistor@mac.com" target="_blank">resistor@mac.com</a>> wrote:</div><br><div><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On Sep 12, 2014, at 10:27 AM, Dan Gohman <<a href="mailto:dan433584@gmail.com" target="_blank">dan433584@gmail.com</a>> wrote:</div><br><div><blockquote class="gmail_quote" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><br>More generally, I don’t see a compelling reason for LLVM to add intrinsic support for the version you’re proposing.  Your choice can easily be expanded into IR, and does not have the wide hardware support (particularly in GPUs) that the IEEE version does.</div></div></blockquote><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">The IEEE version can also be expanded in LLVM IR. And for GPUs, many GPU input languages leave the behavior on NaN unspecified, so it's not obviously the best guide.</div></div></blockquote></div><br><div>That’s not generally true.  HLSL (DirectX), CUDA, OpenCL, and Metal all have defined semantics for NaNs which include not propagating them through min/max.  GLSL (OpenGL) is the odd one out in this area.</div></div></div></blockquote></div></div></div></div></blockquote><div><br>HLSL leaves it undefined:<br><br><a href="http://msdn.microsoft.com/en-us/library/windows/desktop/bb509624%28v=vs.85%29.aspx">http://msdn.microsoft.com/en-us/library/windows/desktop/bb509624%28v=vs.85%29.aspx</a><br><br></div><div>I guess Metal and others only have a "fast-math" flag which (among other things) makes behavior on NaN undefined, but it's my impression that it's a popular flag.<br></div><div><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="word-wrap:break-word"><div><div class="h5"><div><br></div></div></div><div>Also, as a practical issues, many GPUs have ISA-level support for the IEEE-conforming version.  Some (all?) of the AMD GPUs that Matt cares about support it, and PTX has native operations for it as well.  The IR expansion of an IEEE-conforming fmin/fmax is at least three compares + selects, which makes it very difficult to pattern match for these targets.</div></div></blockquote><div><br></div><div>It's 2 compares + selects:<br><br>float nan_swallowing_fmin(float a, float b) {<br>  return b != b ? a : (a < b ? a : b);<br>}<br><br></div><div>which is within the realm of pattern-matching.<br></div><div> </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="word-wrap:break-word"><div><br></div><div>The inverse form (always propagating NaNs) is not widely natively supported.</div></div></blockquote><div> </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="word-wrap:break-word"><div>  I think AArch64 *might* have it?  </div></div></blockquote><div><br><div>It does. In fact, even armv7 has a NaN-propagating min/max:<br></div><br><a href="http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0489i/CIHDEEBE.html">http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0489i/CIHDEEBE.html</a><br></div></div></div></div>