[Libclc-dev] [PATCH 1/2] amdgcn/fmin: Explicitly check for NaNs

[Jeroen Ketema via Libclc-dev]

Mmm,

From the LLVM IR documentation “Follows the IEEE-754 semantics for minNum, which also match for libm’s fmin.”

What does IEEE-754 mean here? 1985 or 2008? If 2008, then the statement is in correct, because libm treats sNaNs and qNaNs in the same way. I’m not sure about 1985 (don’t have access to that version of the spec at the moment).

Jeroen

> On 17 Nov 2017, at 01:46, Jeroen Ketema <j.ketema at xs4all.nl> wrote:
> 
> If I’m not mistaken these all change sNaNs into qNaNs. Looking at [1], this seems reminiscent of ieee_mode. Are you sure the chip is correctly set up before the kernels are run? In particular, the IEEE bit (bit 9) of the Mode Register?
> 
> Jeroen
> 
> [1] http://developer.amd.com/wordpress/media/2013/07/AMD_Sea_Islands_Instruction_Set_Architecture1.pdf
> 
>> On 15 Nov 2017, at 22:16, Jan Vesely via Libclc-dev <libclc-dev at lists.llvm.org> wrote:
>> 
>> On Wed, 2017-11-15 at 11:43 -0800, Matt Arsenault via Libclc-dev wrote:
>>> On 11/15/2017 09:21 AM, Jan Vesely via Libclc-dev wrote:
>>>> v_min instruction fails to handle certain NaNs correctly.
>>>> 
>>>> Signed-off-by: Jan Vesely <jan.vesely at rutgers.edu>
>>>> ---
>>>> Fixes most of fmin CTS on carrizo. It still fails on denormals, but IMO
>>>> that's CTS bug.
>>>> EG/NI does not seem to suffer the same problem.
>>> 
>>> What exact problem are you trying to solve? Do you have an example? NaNs 
>>> should work correctly.
>> 
>> they don't.
>> some nan encodings return incorrect value.
>> examples from CTS:
>> ERROR: fmin: -nan ulp error at {0x1.211a92p-95 (0x10108d49), -nan (0xffa66c5d)}: *0x1.211a92p-95 vs. -nan (0xffe66c5d) at index: 448
>> 
>> ERROR: fmin: nan ulp error at {nan (0x7fba759e), 0x1.94ea58p-89 (0x134a752c)}: *0x1.94ea58p-89 vs. nan (0x7ffa759e) at index: 450
>> 
>> ERROR: fmin: nan ulp error at {nan (0x7f9a4655), -0x1.9ed39p-22 (0xb4cf69c8)}: *-0x1.9ed39p-22 vs. nan (0x7fda4655) at index: 617
>> 
>> ERROR: fmin: nan ulp error at {0x1.303c36p+46 (0x56981e1b), nan (0x7fa7afae)}: *0x1.303c36p+46 vs. nan (0x7fe7afae) at index: 739
>> 
>> it only shows 4 errors because it used 4 testing threads, there might be more.
>> tested on carrizo (fx9800p).
>> 
>> Jan
>> 
>> 
>>> We do have some issues with denorm flushing 
>>> behavior changing on gfx9.
>>> _______________________________________________
>>> Libclc-dev mailing list
>>> Libclc-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/libclc-dev
>> _______________________________________________
>> Libclc-dev mailing list
>> Libclc-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/libclc-dev
>