[libspirv] Define schar overloads via remangling; not source

[frasercrmck]

We were previously achieving the signed char builtin definitions in libspirv via one of two ways. The first was explicitly definining schar overloads of builtins in the source. The second was by remangling 'char' builtins to one of schar or uchar, depending on the host platform.

Since we are defining our builtins in OpenCL C, the plain 'char' type is already a signed type. This presents us with the opportunity to achieve our desired schar builtins solely through remangling. The primary idea is to reduce our libclc/libspirv diff with upstream. We also have the option to introduce signed char builtins upstream. As it stands the schar problem isn't far from the 'half' mangling problem that we also now deal with purely in the remangler.

[frasercrmck]

CC @wenju-he

[ldrumm]

Since we are defining our builtins in OpenCL C, the plain 'char' type is already a signed type.

Does that include ARM?

[frasercrmck]

Since we are defining our builtins in OpenCL C, the plain 'char' type is already a signed type.

Does that include ARM?

To be honest I'm not sure. It should be given the OpenCL C specification (here). I'd say that if ARM is treating char as unsigned for OpenCL code it's a clang (or a user) bug.

[ldrumm]

I'd say that if ARM is treating char as unsigned for OpenCL code it's a clang (or a user) bug.

Agreed. However, clang OpenCL has historically been maintained primarily by ARM, and I think we encountered this before in ComputeAorta. I'm not saying it's a blocker, but it may be worth checking

[ldrumm]

I'd say that if ARM is treating char as unsigned for OpenCL code it's a clang (or a user) bug.

Agreed. However, clang OpenCL has historically been maintained primarily by ARM, and I think we encountered this before in ComputeAorta. I'm not saying it's a blocker, but it may be worth checking

Since we are defining our builtins in OpenCL C, the plain 'char' type is already a signed type.

Does that include ARM?

Resolved via offline demonstration. LGTM

[frasercrmck]

I'd say that if ARM is treating char as unsigned for OpenCL code it's a clang (or a user) bug.

Agreed. However, clang OpenCL has historically been maintained primarily by ARM, and I think we encountered this before in ComputeAorta. I'm not saying it's a blocker, but it may be worth checking

(As discussed offline)

Compiling a simple C and OpenCL C file which casts a char to int shows that OpenCL does indeed seem to be guaranteeing signed chars by default, even for targets like arm and riscv64 where the C code is unsigned.

[wenju-he]

thanks @frasercrmck. This is very nice.