Add a few missing uses of types and enums to XML

[kpet]

• OpenCL 1.0 requires cl_char, etc types
• OpenCL 1.2 and cl_khr+_fp64 require cl_double
• cl_khr_fp16 requires CL_HALF_* constants
• cl_khr_icd requires cl_icd_dispatch
• OpenCL 1.0 requires all the CL_M_* constants. The specification does not state which version defines which constant (see CL_M_* constants unspecified #731)

Change-Id: I8eb34ab1eccf727700662ff5f61823d0e8c48ea1

[kpet]

With the change the only missing uses reported by #730 are vendor definitions and vendor-reserved enums.

[bashbaug]

Thanks for doing this! I have a few comments and suggestions, mostly from a header organization (and generation) point of view.

[bashbaug]

These half constants are also defined in cl_platform.h. Since these are #defines and not typedefs we could define them twice without a diagnostic (assuming they're defined to the same values, which hopefully they are!), though it might be better not to do this.

Do we want to:

1. Consider these constants to be parts of the API, unconditionally, also, by including them as part of "OpenCL 1.0" and not part of the cl_khr_fp16 extension?
2. Take them out of cl_platform.h and define them in cl_ext.h instead, as part of the cl_khr_fp16 extension?
3. Some other solution that involves special-casing these constants in the extension header generation scripts.

Note, I originally thought it was weird that cl_half was in "OpenCL 1.0", especially because cl_double is not, but perhaps this is intended and correct due to the vload_half and vstore_half built-in functions?

[kpet]

There are two identical copies of those definitions in cl_platform.h (MSVC/WIN32 and "others"). We probably ought to fix that too. I can't think of a strong reason for these not to be defined by cl_khr_fp16, maybe apart
from the fact that all applications will directly or indirectly include cl_platform.h but maybe not cl_ext.h. If we needed to have compiler-dependent variants of those definitions (such differences are typically handled in cl_platform.h) then presumably the issues would be generic and worthwhile to solve for all extensions in tooling. Let me outline the resolutions I see:

1. Move the require tags to OpenCL 1.0 and accept that these are always available in OpenCL. They were clearly added by the cl_khr_fp16 spec so this would be a little weird.
2. Move the definitions to their own enum block, require them in cl_khr_fp16 but keep the definitions in cl_platform.h.
3. Move the definitions to their own enum block. require them in cl_khr_fp16 and rely on tooling to generate the definitions as part of cl_ext.h.

I think 1 does not look like a good option. 2 might require a special case in tooling but the headers wouldn't change. 3 looks like the more orthogonal but requires changing the headers.

Note, I originally thought it was weird that cl_half was in "OpenCL 1.0", especially because cl_double is not, but perhaps this is intended and correct due to the vload_half and vstore_half built-in functions?

I haven't done the full search though old references but, on the surface, that seems like a good enough reason.

[bashbaug]

Confirming: we decided to go with (2)? If so, this means we need to add a "denylist" to the header generation script for these enums. Not a big deal, but it's not something I'll do unless we need to do it.