[LLVMdev] [PATCH][RFC]: Add fmin/fmax intrinsics
Owen Anderson
resistor at mac.com
Fri Sep 12 22:13:19 PDT 2014
On Sep 12, 2014, at 5:39 PM, Dan Gohman <dan433584 at gmail.com> wrote:
>
>
> On Fri, Sep 12, 2014 at 3:04 PM, Owen Anderson <resistor at mac.com> wrote:
>
>> 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> 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.
>
>
> HLSL leaves it undefined:
>
> http://msdn.microsoft.com/en-us/library/windows/desktop/bb509624%28v=vs.85%29.aspx
Not exactly. The HLSL language leaves it undefined, but HLSL bytecode specifies that it’s not NaN-propagating:
http://msdn.microsoft.com/en-us/library/windows/desktop/hh447185(v=vs.85).aspx
And I happen to know from experience that a lot of graphics shaders depend on it working that way in practice.
—Owen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140912/fb3a1f2c/attachment.html>
More information about the llvm-dev
mailing list