[LLVMdev] [PATCH][RFC]: Add fmin/fmax intrinsics

Owen Anderson
Mon, 18 Aug 2014 17:00:13 -0000

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.

—Owen

> On Aug 18, 2014, at 1:22 AM, Mueller-Roemer, Johannes Sebastian
<Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de> wrote:
>
> 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.
>
> --
> Johannes S. Mueller-Roemer, MSc
> Wiss. Mitarbeiter - Interactive Engineering Technologies (IET)
>
> Fraunhofer-Institut für Graphische Datenverarbeitung IGD
> Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
> Tel +49 6151 155-606  |  Fax +49 6151 155-139
> johannes.mueller-roemer at igd.fraunhofer.de
<mailto:johannes.mueller-roemer at igd.fraunhofer.de>  |
www.igd.fraunhofer.de <http://www.igd.fraunhofer.de/>
>
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at
cs.uiuc.edu] On Behalf Of Stephen Canon
> Sent: Thursday, August 14, 2014 18:03
> To: Matt Arsenault
> Cc: llvm-commits; LLVM Developers Mailing List
> Subject: Re: [LLVMdev] [PATCH][RFC]: Add fmin/fmax intrinsics
>
> … 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]:
>
>             minNum(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).
>
> So I think your proposed semantics are perfectly reasonable.
>
> – Steve
>
> On Aug 14, 2014, at 10:55 AM, Steve Canon <scanon at apple.com
<mailto:scanon at apple.com>> wrote:
>
> 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.
>
> (Signaling NaNs could still be left unspecified as they're optional in
IEEE-754).
>
> - Steve
>
> Sent from my iPhone
>
>
> On Aug 13, 2014, at 7:38 PM, Matt Arsenault <arsenm2 at gmail.com
<mailto:arsenm2 at gmail.com>> wrote:
>
> Hi,
>
> 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.
>
> This has been proposed before, but never delivered
(http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-December/057128.html
<http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-December/057128.html>)
>
> To summarize:
> 1. If either operand is a NaN, returns the other operand
> 2. If both operands are NaN, returns NaN
> 3. If the operands are equal, returns a value that will compare equal to
both arguments
> 4. In the normal case, returns the smaller / larger operand
> 5. Ignore what to do for signaling NaNs, since that’s what the rest of LLVM
does currently anyway
>
> - Handling of fmin/fmax (+/- 0.0, +/- 0.0)
> 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.
>
> For the purposes of constant folding, I’ve tried to follow the literal
wording which was most explicit for the expected result from OpenCL
(http://www.khronos.org/registry/cl/sdk/1.2/docs/man/xhtml/fmin.html
<http://www.khronos.org/registry/cl/sdk/1.2/docs/man/xhtml/fmin.html>) and
taking the comparison +/-0.0 < +/-0.0 will fail.
>
> This means the constant folded results will be:
>   fmin(0.0, 0.0) = 0.0
>   fmin(0.0, -0.0) = 0.0
>   fmin(-0.0, 0.0) = -0.0
>   fmin(-0.0, -0.0) = -0.0
>
> 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.
>
> <0001-Add-fmin-fmax-intrinsics.patch>
> <0002-Add-basic-fmin-fmax-instcombines.patch>
> <0003-Fold-fmin-fmax-with-infinities.patch>
> <0004-Move-fmin-fmax-constant-folding-logic-into-APFloat.patch>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>
http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/>
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140818/cbeda0c8/attachment.html>