[PATCH 1/7] vstore_half: Make sure the helper function is always inline

Runtimes OpenCL
1

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

2

Add another layer of indirection
This will be used for specific rounding modes

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

3

Add support for rounding suffix

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

4

Passes CTS on carrizo
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>

5

Passes CTS on carrizo
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>

6

Passes CTS on carrizo
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>

7

Passes CTS on carrizo
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>

8

The comments on this patch set look a bit funny to me (multiline with stars as the left margin, don’t see much of that in LLVM). Otherwise, LGTM, although I cannot possibly comment on the implementations of the rounding functions (I assume these are pretty much standard?).

Jeroen

9

The comments on this patch set look a bit funny to me (multiline with
stars as the left margin, don’t see much of that in LLVM).

These follow other longer comments (such as in erf.cl/erfc.cl). LLVM is
in C++ so it prefers C++ style comments. I agree that libclc codestyle
is inconsistent and can use cleanup, but that's for another day.

Otherwise, LGTM,

Thanks.

although I cannot possibly comment on the implementations of the
rounding functions (I assume these are pretty much standard?).

It's my own implementation, _rtz and _rti round to the nearest half
representable float in that direction (except for high order _rti which
relies on half conversion to convert to Inf).

_rtn/_rtp then just choose from the above too based on sign.

_rte pretty much replicates most of the work, and last/qrs bits follow
the standard (hence extra comments). I assume that the compiler is able
to remove most of the duplicities.

regards,
Jan

10

> The comments on this patch set look a bit funny to me (multiline with
> stars as the left margin, don’t see much of that in LLVM).

These follow other longer comments (such as in erf.cl/erfc.cl). LLVM is
in C++ so it prefers C++ style comments. I agree that libclc codestyle
is inconsistent and can use cleanup, but that's for another day.

> Otherwise, LGTM,

Thanks.

> although I cannot possibly comment on the implementations of the
> rounding functions (I assume these are pretty much standard?).

It's my own implementation, _rtz and _rti round to the nearest half
representable float in that direction (except for high order _rti which
relies on half conversion to convert to Inf).

_rtn/_rtp then just choose from the above too based on sign.

_rte pretty much replicates most of the work, and last/qrs bits follow
the standard (hence extra comments). I assume that the compiler is able
to remove most of the duplicities.

Hi,

is the clarification good enough, or do you want to see some changes
before I push the series?

thanks,
Jan

11

The comments on this patch set look a bit funny to me (multiline with
stars as the left margin, don’t see much of that in LLVM).

These follow other longer comments (such as in erf.cl/erfc.cl). LLVM is
in C++ so it prefers C++ style comments. I agree that libclc codestyle
is inconsistent and can use cleanup, but that's for another day.

Otherwise, LGTM,

Thanks.

although I cannot possibly comment on the implementations of the
rounding functions (I assume these are pretty much standard?).

It's my own implementation, _rtz and _rti round to the nearest half
representable float in that direction (except for high order _rti which
relies on half conversion to convert to Inf).

_rtn/_rtp then just choose from the above too based on sign.

_rte pretty much replicates most of the work, and last/qrs bits follow
the standard (hence extra comments). I assume that the compiler is able
to remove most of the duplicities.

Hi,

is the clarification good enough, or do you want to see some changes
before I push the series?

Was good enough.

Jeroen