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

[Owen Anderson]

> On Sep 12, 2014, at 2:24 PM, Owen Anderson <resistor at mac.com> wrote:
> 
> 
>> On Sep 12, 2014, at 10:27 AM, Dan Gohman <dan433584 at gmail.com <mailto:dan433584 at gmail.com>> wrote:
>> 
>> 
>> 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.
>> 
>> 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.
> 
> That’s not generally true.  HLSL (DirectX), CUDA, OpenCL, and Metal all have defined semantics for NaNs which include not propagating them through min/max.  GLSL (OpenGL) is the odd one out in this area.

Also, as a practical issues, many GPUs have ISA-level support for the IEEE-conforming version.  Some (all?) of the AMD GPUs that Matt cares about support it, and PTX has native operations for it as well.  The IR expansion of an IEEE-conforming fmin/fmax is at least three compares + selects, which makes it very difficult to pattern match for these targets.

The inverse form (always propagating NaNs) is not widely natively supported.  I think AArch64 *might* have it?  MAXPS in SSE performs a ternary operator form that doesn’t match either definition.

—Owen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140912/f3200ed8/attachment.html>