[PATCH 1/6] Move cl_khr_fp64 exntension enablement to gentype include lists

This will make adding cl_khr_fp16 support easier

Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>

No changes wrt CTS

Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>

No changes wrt CTS

Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>

Passes CTS on Carrizo

Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>

v2: Use select instead of bitselect to consolidate scalar and vector
versions

Passes CTS on Carrizo

Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>

Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>

ping

Passes CTS on Carrizo

Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
---
generic/include/clc/relational/select.h | 12 +++++++-
generic/include/clc/relational/select.inc | 25 ++++++++++++++++
generic/lib/SOURCES | 1 +
generic/lib/relational/select.cl | 7 +++++
generic/lib/relational/select.inc | 47 +++++++++++++++++++++++++++++++
5 files changed, 91 insertions(+), 1 deletion(-)
create mode 100644 generic/include/clc/relational/select.inc
create mode 100644 generic/lib/relational/select.cl
create mode 100644 generic/lib/relational/select.inc

diff --git a/generic/include/clc/relational/select.h b/generic/include/clc/relational/select.h
index 33a6909..d20deae 100644
--- a/generic/include/clc/relational/select.h
+++ b/generic/include/clc/relational/select.h
@@ -1 +1,11 @@
-#define select(a, b, c) ((c) ? (b) : (a))
+/* Duplciate these so we don't have to distribute utils.h */
+#define __CLC_CONCAT(x, y) x ## y
+#define __CLC_XCONCAT(x, y) __CLC_CONCAT(x, y)
+
+#define __CLC_BODY <clc/relational/select.inc>
+#include <clc/math/gentype.inc>
+#define __CLC_BODY <clc/relational/select.inc>
+#include <clc/integer/gentype.inc>
+
+#undef __CLC_CONCAT
+#undef __CLC_XCONCAT

I don't mind the previous patches where you removed the #undef
__CLC_BODY lines (those were all in lib/*), but
don't we want to clean up after ourselves in the installed headers?

I'd prefer to undef __CLC_BODY here, if possible.

--Aaron

Besides my comment on patch 4, the series is:
Reviewed-by: Aaron Watry <awatry@gmail.com>

--Aaron

> Passes CTS on Carrizo
>
> Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
> ---
> generic/include/clc/relational/select.h | 12 +++++++-
> generic/include/clc/relational/select.inc | 25 ++++++++++++++++
> generic/lib/SOURCES | 1 +
> generic/lib/relational/select.cl | 7 +++++
> generic/lib/relational/select.inc | 47 +++++++++++++++++++++++++++++++
> 5 files changed, 91 insertions(+), 1 deletion(-)
> create mode 100644 generic/include/clc/relational/select.inc
> create mode 100644 generic/lib/relational/select.cl
> create mode 100644 generic/lib/relational/select.inc
>
> diff --git a/generic/include/clc/relational/select.h b/generic/include/clc/relational/select.h
> index 33a6909..d20deae 100644
> --- a/generic/include/clc/relational/select.h
> +++ b/generic/include/clc/relational/select.h
> @@ -1 +1,11 @@
> -#define select(a, b, c) ((c) ? (b) : (a))
> +/* Duplciate these so we don't have to distribute utils.h */
> +#define __CLC_CONCAT(x, y) x ## y
> +#define __CLC_XCONCAT(x, y) __CLC_CONCAT(x, y)
> +
> +#define __CLC_BODY <clc/relational/select.inc>
> +#include <clc/math/gentype.inc>
> +#define __CLC_BODY <clc/relational/select.inc>
> +#include <clc/integer/gentype.inc>
> +
> +#undef __CLC_CONCAT
> +#undef __CLC_XCONCAT

I don't mind the previous patches where you removed the #undef
__CLC_BODY lines (those were all in lib/*), but
don't we want to clean up after ourselves in the installed headers?

I'd prefer to undef __CLC_BODY here, if possible.

gentype.inc (both of them) undefs this for us. compiler would complain
(__CLC_BODY redefined in the next instance) otherwise.
It's not nicely symmetric, but it should be correct.

Jan

Passes CTS on Carrizo

Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>

generic/include/clc/relational/select.h | 12 ++++++±
generic/include/clc/relational/select.inc | 25 ++++++++++++++++
generic/lib/SOURCES | 1 +
generic/lib/relational/select.cl | 7 +++++
generic/lib/relational/select.inc | 47 +++++++++++++++++++++++++++++++
5 files changed, 91 insertions(+), 1 deletion(-)
create mode 100644 generic/include/clc/relational/select.inc
create mode 100644 generic/lib/relational/select.cl
create mode 100644 generic/lib/relational/select.inc

diff --git a/generic/include/clc/relational/select.h b/generic/include/clc/relational/select.h
index 33a6909…d20deae 100644
— a/generic/include/clc/relational/select.h
+++ b/generic/include/clc/relational/select.h
@@ -1 +1,11 @@
-#define select(a, b, c) ((c) ? (b) : (a))
+/* Duplciate these so we don’t have to distribute utils.h */
+#define __CLC_CONCAT(x, y) x ## y
+#define __CLC_XCONCAT(x, y) __CLC_CONCAT(x, y)
+
+#define __CLC_BODY <clc/relational/select.inc>
+#include <clc/math/gentype.inc>
+#define __CLC_BODY <clc/relational/select.inc>
+#include <clc/integer/gentype.inc>
+
+#undef __CLC_CONCAT
+#undef __CLC_XCONCAT

I don’t mind the previous patches where you removed the #undef
__CLC_BODY lines (those were all in lib/*), but
don’t we want to clean up after ourselves in the installed headers?

I’d prefer to undef __CLC_BODY here, if possible.

gentype.inc (both of them) undefs this for us. compiler would complain
(__CLC_BODY redefined in the next instance) otherwise.
It’s not nicely symmetric, but it should be correct.

Sounds good.

Series looks good to me.

–Aaron

Hi Jan,

Sorry for being a bit late with this. Why was this change to select needed? The ternary operator should behave like select in the case of vectors and is implemented in Clang as such.

Jeroen

Hi Jan,

Sorry for being a bit late with this. Why was this change to select
needed? The ternary operator should behave like select in the case of
vectors and is implemented in Clang as such.

Ah, right. The specs explicitly states that vector ?: is equivalent to
select. Even if it's counter-intuitive (both in terms of truth
evaluation, and the fact that it evaluates both expressions).
I'd still prefer to have a function rather than macro, but the #else
path definitely redundant.

thanks,
Jan

Hi Jan,

Sorry for being a bit late with this. Why was this change to select
needed? The ternary operator should behave like select in the case of
vectors and is implemented in Clang as such.

Ah, right. The specs explicitly states that vector ?: is equivalent to
select. Even if it’s counter-intuitive (both in terms of truth
evaluation, and the fact that it evaluates both expressions).
I’d still prefer to have a function rather than macro, but the #else
path definitely redundant.

Yes, agreed on keeping the function. It probably results in slightly better
compiler errors and warnings.

Jeroen

>
> > Hi Jan,
> >
> > Sorry for being a bit late with this. Why was this change to select
> > needed? The ternary operator should behave like select in the case of
> > vectors and is implemented in Clang as such.
>
> Ah, right. The specs explicitly states that vector ?: is equivalent to
> select. Even if it's counter-intuitive (both in terms of truth
> evaluation, and the fact that it evaluates both expressions).
> I'd still prefer to have a function rather than macro, but the #else
> path definitely redundant.

Yes, agreed on keeping the function. It probably results in slightly better
compiler errors and warnings.

sorry for the delay, I've been mostly travelling in past week.
The change required changes to minmag/maxmag, to accomodate element
bitwidth restrictions of select calls.
I've a patch ready that removes the bitselect path. I'll post it after
the CTS finishes.

thanks,
Jan

Fix half precision implementation
Vector ?: operator should behave exactly as select
Passes CTS on carrizo

Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>

LGTM!

Thanks.

Jeroen