<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 18, 2014 at 12:32 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">Hi Carter,<div><br></div><div>I would strongly advise you against this direction. I’m aware of two directions that existing languages go in defining min/max operations:</div><div><br></div><div>- IEEE 754, C, Fortran, Matlab, OpenCL, and HLSL all define it not to propagate NaNs</div><div>- C++ (std::min/std::max) and OpenGL define it in the trinary operator manner: (a < b) ? a : b</div><div><br></div><div>What you’re proposing does not match any existing languages that I’m aware of, and seems likely to hamper cross-language portability for you in the future.</div></div></blockquote><div><br></div><div>At a quick glance, I found JavaScript [0] and Java [1] both have a min and max that propagate NaN.<br><br>[0] <a href="http://people.mozilla.org/~jorendorff/es6-draft.html#sec-math.max" target="_blank">http://people.mozilla.org/~jorendorff/es6-draft.html#sec-math.max</a><br>[1] <a href="http://docs.oracle.com/javase/7/docs/api/java/lang/Math.html#max%28double,%20double%29" target="_blank">http://docs.oracle.com/javase/7/docs/api/java/lang/Math.html#max%28double,%20double%29</a><br><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><br></div><div>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><br></div><div>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.<br><br></div><div>Consider also this: The IEEE version exists within a spec where it's assumed that programmers have elaborate access to information about floating-point exceptions. In practice, programming languages and environments have not been able to reliably deliver this level of access. NaN is one of the few ways left to determine whether an exception has occurred (and even NaN isn't always enough), and so the motivation for NaN propagation in practice may be greater than what it was in the IEEE spec.<br></div><div><br></div><div>Dan<br> <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"><span><font color="#888888"><div><br></div><div>—Owen</div></font></span><div><div><div><br></div><div><br><div><blockquote type="cite"><div>On Aug 18, 2014, at 12:00 PM, Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>> wrote:</div><br><div><div dir="ltr">would it be in scope to have intrinsics analogues for fmin/fmax that return Nan if either arg is a nan? <div>Julia Lang and GHC Haskell are both likely to change their definitions of min/max on floats/doubles to return nan if either arg is Nan.</div>
<div>See <a href="https://github.com/JuliaLang/julia/issues/7866" target="_blank">here </a> for the julia lang discussion, and I'm amidst putting together the analogous propose for GHC Haskell. </div><div><br></div><div>My understanding is the NAN evading semantics of fmin/fmax in the IEEE spec are motivated by using NaN to encode "this data is missing" rather than the more common "this is the result of an erroneous computation". Granted, such an alternative nan returning fmin/fmax can be written a derived llvm operation too, but they could just as easily benefit from llvm integration. </div>
<div><br></div><div>I hope this suggestion/question is in scope for this thread, if not I appologize for jumping in.</div><div><br></div><div>thanks!</div><div>-Carter</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Mon, Aug 18, 2014 at 1:00 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">This is a problem with all floating point folding, not just with these operations. What Matt is proposing is consistent with how we fold other libm intrinsics.<div><br></div><div>—Owen<br>
<div><br><div><blockquote type="cite"><div><div><div>On Aug 18, 2014, at 1:22 AM, Mueller-Roemer, Johannes Sebastian <<a href="mailto:Johannes.Sebastian.Mueller-Roemer@igd.fraunhofer.de" target="_blank">Johannes.Sebastian.Mueller-Roemer@igd.fraunhofer.de</a>> wrote:</div>
<br></div></div><div><div><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">
<div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:"Times New Roman",serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)" lang="EN-US">Wouldn’t it be better to use the target’s implementation (if there is one) instead of generically using one option for constant folding? Otherwise target behavior and constant folded behavior would differ, which should be avoided if possible IMO.<u></u><u></u></span></div>
<div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:"Times New Roman",serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)" lang="EN-US"> </span></div><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:"Times New Roman",serif">
<span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">--<u></u><u></u></span></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:"Times New Roman",serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Johannes S. Mueller-Roemer, MSc<u></u><u></u></span></div>
<div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:"Times New Roman",serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Wiss. Mitarbeiter - Interactive Engineering Technologies (IET)<u></u><u></u></span></div>
<div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:"Times New Roman",serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> </span></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:"Times New Roman",serif">
<span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Fraunhofer-Institut für Graphische Datenverarbeitung IGD<u></u><u></u></span></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:"Times New Roman",serif">
<span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Fraunhoferstr. 5 | 64283 Darmstadt | Germany<u></u><u></u></span></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:"Times New Roman",serif">
<span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Tel <a href="tel:%2B49%206151%20155-606" value="+496151155606" target="_blank">+49 6151 155-606</a> | Fax <a href="tel:%2B49%206151%20155-139" value="+496151155139" target="_blank">+49 6151 155-139</a><u></u><u></u></span></div>
<div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:"Times New Roman",serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><a href="mailto:johannes.mueller-roemer@igd.fraunhofer.de" style="color:purple;text-decoration:underline" target="_blank">johannes.mueller-roemer@igd.fraunhofer.de</a> | <span> </span><a href="http://www.igd.fraunhofer.de/" style="color:purple;text-decoration:underline" target="_blank">www.igd.fraunhofer.de</a><u></u><u></u></span></div>
</div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:"Times New Roman",serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> </span></div><div><div style="border-style:solid none none;border-top:1pt solid rgb(181,196,223);padding:3pt 0in 0in">
<div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:"Times New Roman",serif"><b><span style="font-size:10pt;font-family:Tahoma,sans-serif" lang="EN-US">From:</span></b><span style="font-size:10pt;font-family:Tahoma,sans-serif" lang="EN-US"><span> </span><a href="mailto:llvmdev-bounces@cs.uiuc.edu" target="_blank">llvmdev-bounces@cs.uiuc.edu</a> [<a href="mailto:llvmdev-bounces@cs.uiuc.edu" target="_blank">mailto:llvmdev-bounces@cs.uiuc.edu</a>]<span> </span><b>On Behalf Of<span> </span></b>Stephen Canon<br>
<b>Sent:</b><span> </span>Thursday, August 14, 2014 18:03<br><b>To:</b><span> </span>Matt Arsenault<br><b>Cc:</b><span> </span>llvm-commits; LLVM Developers Mailing List<br><b>Subject:</b><span> </span>Re: [LLVMdev] [PATCH][RFC]: Add fmin/fmax intrinsics<u></u><u></u></span></div>
</div></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:"Times New Roman",serif"><u></u> <u></u></div><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:"Times New Roman",serif">
… actually, now that I’m able double-check this, I’m quite surprised to find that we didn’t define fmax(+0,–0) in IEEE–754, which says [paraphrased]:<u></u><u></u></div></div><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:"Times New Roman",serif">
<u></u> <u></u></div></div><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:"Times New Roman",serif"><span> <span> </span></span><b>minNum</b>(x,y) is x if x < y, y if y < x, and the number if one is a number and the other is NaN. Otherwise, it is either x or y (this means results might differ among implementations).<u></u><u></u></div>
</div><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:"Times New Roman",serif"><u></u> <u></u></div></div><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:"Times New Roman",serif">
So I think your proposed semantics are perfectly reasonable.<u></u><u></u></div></div><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:"Times New Roman",serif"><u></u> <u></u></div></div><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:"Times New Roman",serif">
– Steve<u></u><u></u></div></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:"Times New Roman",serif"><u></u> <u></u></div><div><blockquote style="margin-top:5pt;margin-bottom:5pt"><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:"Times New Roman",serif">
On Aug 14, 2014, at 10:55 AM, Steve Canon <<a href="mailto:scanon@apple.com" style="color:purple;text-decoration:underline" target="_blank">scanon@apple.com</a>> wrote:<u></u><u></u></div></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:"Times New Roman",serif">
<u></u> <u></u></div><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:"Times New Roman",serif">I have no position on whether or not these should be added, but if they are they should match the IEEE 754 semantics, which fully specify all of these details.<br>
<br>(Signaling NaNs could still be left unspecified as they're optional in IEEE-754).<br><br>- Steve<br><br>Sent from my iPhone<br><br><br><u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:"Times New Roman",serif">
On Aug 13, 2014, at 7:38 PM, Matt Arsenault <<a href="mailto:arsenm2@gmail.com" style="color:purple;text-decoration:underline" target="_blank">arsenm2@gmail.com</a>> wrote:<br><br>Hi,<br><br>I’d like to re-propose adding intrinsics for fmin / fmax. These can be used to implement the equivalent libm functions as defined in C99 and OpenCL, which R600 and AArch64 at least have instructions with the same semantics. This is not equivalent to a simple fcmp + select due to its handling of NaNs.<span> </span><br>
<br>This has been proposed before, but never delivered (<a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-December/057128.html" style="color:purple;text-decoration:underline" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-December/057128.html</a>)<br>
<br>To summarize:<br>1. If either operand is a NaN, returns the other operand<br>2. If both operands are NaN, returns NaN<br>3. If the operands are equal, returns a value that will compare equal to both arguments<br>4. In the normal case, returns the smaller / larger operand<br>
5. Ignore what to do for signaling NaNs, since that’s what the rest of LLVM does currently anyway<br><br>- Handling of fmin/fmax (+/- 0.0, +/- 0.0)<br>Point 3 is worded as such because this doesn’t seem particularly well specified by any standard I’ve looked at. The most explicit mention of this I’ve found is a footnote in C99 that “Ideally, fmax would be sensitive to the sign of zero, for example fmax(-0.0, 0.0) would return +0; however, implementation in software might be impractical.” It doesn’t really state what the expected behavior is. glibc and OS X’s libc disagree on the (+0, -0) and (-0, +0) cases. To resolve this, the semantics of the intrinsic will be that either will be OK as long as the result compares equal.<br>
<br>For the purposes of constant folding, I’ve tried to follow the literal wording which was most explicit for the expected result from OpenCL (<a href="http://www.khronos.org/registry/cl/sdk/1.2/docs/man/xhtml/fmin.html" style="color:purple;text-decoration:underline" target="_blank">http://www.khronos.org/registry/cl/sdk/1.2/docs/man/xhtml/fmin.html</a>) and taking the comparison +/-0.0 < +/-0.0 will fail.<br>
<br>This means the constant folded results will be:<br> fmin(0.0, 0.0) = 0.0<br> fmin(0.0, -0.0) = 0.0<br> fmin(-0.0, 0.0) = -0.0<br> fmin(-0.0, -0.0) = -0.0<br><br>Other options would be to always use +0.0, or to be sensitive to the sign and claim -0.0 is less than 0.0.<br>
<br><0001-Add-fmin-fmax-intrinsics.patch><br><0002-Add-basic-fmin-fmax-instcombines.patch><br><0003-Fold-fmin-fmax-with-infinities.patch><br><0004-Move-fmin-fmax-constant-folding-logic-into-APFloat.patch><u></u><u></u></div>
</div></blockquote></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:"Times New Roman",serif"><u></u> <u></u></div></div></div></div><span 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;float:none;display:inline!important">_______________________________________________</span><br 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">
<span 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;float:none;display:inline!important">LLVM Developers mailing list</span><br 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">
<a href="mailto:LLVMdev@cs.uiuc.edu" style="color:purple;text-decoration:underline;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" target="_blank">LLVMdev@cs.uiuc.edu</a><span 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;float:none;display:inline!important"><span> </span> </span><a href="http://llvm.cs.uiuc.edu/" style="color:purple;text-decoration:underline;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" target="_blank">http://llvm.cs.uiuc.edu</a><br 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">
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" style="color:purple;text-decoration:underline;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" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a></div>
</blockquote></div><br></div></div></div><br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu/" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div><br></div>
</div></blockquote></div><br></div></div></div></div><br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div><br></div></div>