[LLVMdev] max/min intrinsics
Schoedel, Kevin P
kevin.p.schoedel at intel.com
Mon Dec 17 10:50:12 PST 2012
On Wednesday, December 05, 2012 at 2:48 PM, Chris Lattner wrote:
> > What does the community think?
> It seems inevitable. For the floating point version, please make it very clear
> what the behavior of max(-0,+0) and related cases are.
The following is our current proposal for llvm.fmax/fmin.*:
 If exactly one argument is a NaN, the intrinsic returns the other argument.
 If both arguments are NaN, the intrinsic returns a NaN.
 An SNaN may behave as a QNaN.
 If the arguments compare equal, the intrinsic returns a value that compares equal to both arguments.
 Otherwise, the intrinsic returns the greater/lesser of the two arguments.
Rationale and notes:
Points  and  match the C/Posix library functions' specs.
Point  matches the OpenCL library functions, and may permit some implementations to test for NaNs less expensively.
Point  accounts for fmax(-0,+0) in IEEE 754 arithmetic, and any similar cases that might exist in other systems (LLVM needs a VAX backend). IEEE specifies that comparisons ignore the sign of zero, so requiring fmax to order ±0 would be expensive on many systems, and is not necessary to support common library functions.
The intrinsics can replace calls to the C and OpenCL library functions.
The intrinsics can be implemented as calls to the C or OpenCL library functions. They can also be implemented by IEEE 754 maxNum()/minNum() operations (but not vice versa).
The intrinsics are not equivalent to an fcmp/select sequence.
Kevin Schoedel, Software Developer, Intel of Canada
<kevin.p.schoedel at intel.com> +1 (519) 772-2580
Disclaimer: the above just might possibly contain a
statement that is not an official opinion of Intel.
More information about the llvm-dev