[LLVMdev] max/min intrinsics

[Schoedel, Kevin P]

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.*:

[1] If exactly one argument is a NaN, the intrinsic returns the other argument.
[2] If both arguments are NaN, the intrinsic returns a NaN.
[3] An SNaN may behave as a QNaN.
[4] If the arguments compare equal, the intrinsic returns a value that compares equal to both arguments.
[5] Otherwise, the intrinsic returns the greater/lesser of the two arguments.

Rationale and notes:

Points [1] and [2] match the C/Posix library functions' specs.

Point [3] matches the OpenCL library functions, and may permit some implementations to test for NaNs less expensively.

Point [4] 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.