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.