[PATCH 1/1] math: Use single precision builtin in sp fdim path

Fixes fdim piglit on Turks

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

Fixes fdim piglit on Turks

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

Not sure when llvm started inserting double promotion:
<unknown>:0:0: in function test_1_fdim_float void (float addrspace(1)*, float addrspace(1)*, float addrspace(1)*): unsupported call to function __extendsfdf2

generic/lib/math/fdim.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/generic/lib/math/fdim.inc b/generic/lib/math/fdim.inc
index a67c76e..0e57513 100644
--- a/generic/lib/math/fdim.inc
+++ b/generic/lib/math/fdim.inc
@@ -25,7 +25,7 @@
_CLC_OVERLOAD _CLC_DEF __CLC_GENTYPE fdim(__CLC_GENTYPE x, __CLC_GENTYPE y) {
     if (__builtin_isnan(x) || __builtin_isnan(y))
         return as_float(QNANBITPATT_SP32);
- return __builtin_fmax(x - y, 0);
+ return __builtin_fmaxf(x - y, 0);

Is there a reason we aren't just calling the OpenCL builtin fmax ?

-Tom

Fixes fdim piglit on Turks

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

Not sure when llvm started inserting double promotion:
:0:0: in function test_1_fdim_float void (float addrspace(1), float addrspace(1), float addrspace(1)*): unsupported call to function __extendsfdf2

generic/lib/math/fdim.inc | 2 ±
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/generic/lib/math/fdim.inc b/generic/lib/math/fdim.inc
index a67c76e…0e57513 100644
— a/generic/lib/math/fdim.inc
+++ b/generic/lib/math/fdim.inc
@@ -25,7 +25,7 @@
_CLC_OVERLOAD _CLC_DEF __CLC_GENTYPE fdim(__CLC_GENTYPE x, __CLC_GENTYPE y) {
if (__builtin_isnan(x) || __builtin_isnan(y))
return as_float(QNANBITPATT_SP32);

  • return __builtin_fmax(x - y, 0);
  • return __builtin_fmaxf(x - y, 0);

Is there a reason we aren’t just calling the OpenCL builtin fmax ?

Reason? Or good reason?

If we change this to either __builtin_fmaxf or fmax (I’d go with that), should we also make that an explicit 0.0f?

–Aaron

>
> >
> > Fixes fdim piglit on Turks
> >
> > Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
> > ---
> >
> > Not sure when llvm started inserting double promotion:
> > <unknown>:0:0: in function test_1_fdim_float void (float
> > addrspace(1)*,
> float addrspace(1)*, float addrspace(1)*): unsupported call to
> function
> __extendsfdf2
> >
> >
> > generic/lib/math/fdim.inc | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/generic/lib/math/fdim.inc
> > b/generic/lib/math/fdim.inc
> > index a67c76e..0e57513 100644
> > --- a/generic/lib/math/fdim.inc
> > +++ b/generic/lib/math/fdim.inc
> > @@ -25,7 +25,7 @@
> > _CLC_OVERLOAD _CLC_DEF __CLC_GENTYPE fdim(__CLC_GENTYPE x,
> __CLC_GENTYPE y) {
> >
> > if (__builtin_isnan(x) || __builtin_isnan(y))
> > return as_float(QNANBITPATT_SP32);
> > - return __builtin_fmax(x - y, 0);
> > + return __builtin_fmaxf(x - y, 0);
> Is there a reason we aren't just calling the OpenCL builtin fmax ?
>
Reason? Or good reason?

If we change this to either __builtin_fmaxf or fmax (I'd go with
that),
should we also make that an explicit 0.0f?

Even with 0, the compiler should pick the correct fmax variant (1
conversion vs. 2 conversions), though I agree that the code would be
nicer.

My reason for sticking with __builtin_fmaxf was that there are no
overloads and it forces conversion to float.
It also provides kind of separation between API and it's
implementation, but I'm not sure we wollow it in libclc.

I'll send v2 using 'fmax(x -y, 0.0f)' if that's the consensus.

Jan

Fixes fdim piglit on Turks

v2: use CL fmax instead of __builtin

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