[libclc] Create an internal 'clc' builtins library

[frasercrmck]

Some libclc builtins currently use internal builtins prefixed with
'_clc' for various reasons, e.g., to avoid naming clashes.

This commit formalizes this concept by starting to isolate the
definitions of these internal clc builtins into a separate
self-contained bytecode library, which is linked into each target's
libclc OpenCL builtins before optimization takes place.

The goal of this step is to allow additional libraries of builtins
that provide entry points (or bindings) that are not written in OpenCL C
but still wish to expose OpenCL-compatible builtins. By moving the
implementations into a separate self-contained library, entry points can
share as much code as possible without going through OpenCL C.

The overall structure of the internal clc library is similar to the
current OpenCL structure, with SOURCES files and targets being able to
override the definitions of builtins as needed. The idea is that the
OpenCL builtins will begin to need fewer target-specific overrides, as
those will slowly move over to the clc builtins instead.

Another advantage of having a separate bytecode library with the CLC
implementations is that we can internalize the symbols when linking it
(separately), whereas currently the CLC symbols make it into the final
builtins library (and perhaps even the final compiled binary).

This patch starts of with 'dot' as it's relatively self-contained, as
opposed to most of the maths builtins which tend to pull in other
builtins.

We can also start to clang-format the builtins as we go, which should
help to modernize the codebase.

[frasercrmck]

CC @rjodinchr. I realise now that this idea may prove problematic for clspv/clspv64 targets. If this idea were to taken further, things like OpenCL minmag would call __clc_minmag which would call __clc_fabs (e.g.), but I notice fabs is not implemented in clspv* libclc and it's left as external declarations. What exactly is happening with clspv libclc builtins? Same question for conversions, etc.

[rjodinchr]

CC @rjodinchr. I realise now that this idea may prove problematic for clspv/clspv64 targets. If this idea were to taken further, things like OpenCL minmag would call __clc_minmag which would call __clc_fabs (e.g.), but I notice fabs is not implemented in clspv* libclc and it's left as external declarations. What exactly is happening with clspv libclc builtins? Same question for conversions, etc.

clspv has a native support for fabs, it does not need libclc to define that function. But as I understand that change, maybe clspv will need to add alias for some __clc_<something>, but it should not be a big issue I believe.

[frasercrmck]

CC @rjodinchr. I realise now that this idea may prove problematic for clspv/clspv64 targets. If this idea were to taken further, things like OpenCL minmag would call __clc_minmag which would call __clc_fabs (e.g.), but I notice fabs is not implemented in clspv* libclc and it's left as external declarations. What exactly is happening with clspv libclc builtins? Same question for conversions, etc.

clspv has a native support for fabs, it does not need libclc to define that function. But as I understand that change, maybe clspv will need to add alias for some __clc_<something>, but it should not be a big issue I believe.

Thanks for the quick reply! It makes sense why you don't need certain symbols. Glad to hear you don't think it'll be a problem.

I'm still not sure how I feel about going from OpenCL to the CLC layer then "back" to OpenCL again, though. I wonder if a system of macros would help obscure this somehow (#define __clc_fabs fabs for clspv). I can't say I'm jumping at the chance to introduce more preprocessor logic though.

[frasercrmck]

ping