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

[Jan Vesely via Libclc-dev]

On Thu, 2017-11-16 at 23:54 -0800, Matt Arsenault wrote:
> > On Nov 16, 2017, at 18:06, Jan Vesely via Libclc-dev <libclc-dev at lists.llvm.org> wrote:
> > 
> > On Fri, 2017-11-17 at 01:10 +0000, Arsenault, Matthew via Libclc-dev
> > wrote:
> > > The compiler always assumes IEEE mode is enabled for compute kernels.
> > > I'm not sure if the driver respects that or not.
> > 
> > right, it sets ieee_mode = 1. but that's not what OpenCL expects for
> > minnum/maxnum.
> > 
> > "fmin and fmax behave as defined by C99 and may not match the IEEE 754-
> > 2008 definition for minNum and
> > maxNum with regard to signaling NaNs. Specifically, signaling NaNs may
> > behave as quiet NaNs."
> > 
> > indeed, clearing the flag fixes the problem
> > 
> > so what would be the correct solution here.
> > 1.) change llvm to not set ieee_mode for opencl compute?
> > 2.) change clover to ignore/override llvm provided ieee_mode setting (I
> > assume this is passed in dispatch packet)?
> > 3.) patch this in libclc? (we might have to do this for older llvm if
> > 1. is the proper fix)
> 
> rocm-device-libs uses canonicalize on the inputs. I think it may only
> be necessary on the inputs. We also are missing optimizations to
> eliminate some redundant canonicalizes

what's the reason to keep the ieee mode?
GCN3 specs only describe semantic change for v_max_f32, v_min_f32, and
v_max_f64 (not even v_min_f64)
the flag description specifically mentions handling of snan which is
not required for OpenCL.

rocm libs work around the behaviour, OpenCL requires not to follow the
behaviour and GL compute does not care.
Can't we just drop it?


Jan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://lists.llvm.org/pipermail/libclc-dev/attachments/20171117/57764e36/attachment-0001.sig>