[OpenCL] atomic_double requires cl_khr_fp64 enabled

Currently Clang requires cl_khr_fp64 enabled to use atomic_double. This seems to be a bug.

In OpenCL 2.0 fp64 is an optional feature. If platform supports it, there is no need to enable cl_khr_fp64 to use it. Actually in OpenCL 2.0 spec cl_khr_fp64 is not defined.

I plan to fix that if all agree it is a bug.

What's your opinion? Thanks.

Sam

One correction: doubles became optional core feature in OpenCL 1.2.

I’m agree that it’s a bug, but I’d like to discuss the ideas on how to fix it.

There should be some way to let clang know that doubles are not supported by OpenCL platform and it’s expected to get diagnostics in this case.

OpenCL C++ compiler introduces compiler knob for that. “cl-fp64-enable”

https://github.com/KhronosGroup/SPIR/blob/spirv-1.1/include/clang/Driver/CC1Options.td#L606

We can use that.

Currently double is automatically enabled in Clang for –cl-std=CL2.0. We could enable double only under cl-fp64-enable.

Sam

Then we can let Clang define macro cl_khr_fp64 when cl-fp64-enable is on. Then the header file will use #ifdef cl_khr_fp64 to enable double type builtin functions.

Sam

In addition to that we will have to modify diagnostics message a bit:

  • for OpenCL before v1.2 we should require cl_khr_fp64 (as it’s done right now)

  • for OpenCL v1.2+ let user know that doubles are not supported by the platform if it’s not enabled by compiler option.

Does it make sense?

Hi Sam,

Actually in OpenCL 2.0 spec cl_khr_fp64 is not defined.

It seems to be in OpenCL 2.0 for the backwards compatibility (Table 4.3), but I agree Spec doesn’t seem to require it for atomic_double types. Btw, conformance tests are still enabling it though.

Cheers,

Anastasia

I am not quite clear how does the command line flag help us or how is it different from enabling the pragma? If the flag is being passed but the target doesn’t support the extension what should happen then?

My understanding of what we are missing in Clang is a way to specify and know what extensions are supported by the target compiled for. We currently have an extension list which are enabled, but the list of supported extensions (to be enabled) is missing, which could come from the target info in my opinion or some sort of that. Not sure it’s correct to have it given from the user. What do you think about this?

Anastasia

I am not quite clear how does the command line flag help us or how is it different from enabling the pragma?

Flag says whether ‘optional core feature’ is supported by the device or not. If the feature is not supported, but it’s used in the program, compiler should report an error.

The difference between ‘optional core feature’ and ‘language extension’ is that pragma is required only for extensions.

If the flag is being passed but the target doesn’t support the extension what should happen then?

It would be OpenCL run-time error. ‘Flag solution’ implies that it’s OpenCL run-time responsibility to set the flags that configures clang to enable/disable optional core features support. It’s not user’s responsibility in case of online compilation.

Offline compilers (e.g. SPIR generators) should implicitly enable all optional core features/extensions at compile time and let the OpenCL run-time to reject the SPIR files that require unsupported features at run time. Flags are helpful for vendor specific compiler that should enable only extensions supported by vendor’s devices.

My understanding of what we are missing in Clang is a way to specify and know what extensions are supported by the target compiled for. We currently have an extension list which are enabled, but the list of supported extensions (to be enabled) is missing, which could come from the target info in my opinion or some sort of that. Not sure it’s correct to have it given from the user. What do you think about this?

You are right. The same problem as Sam described for ‘doubles’ optional core feature is also applied to the OpenCL kernel language extensions.

I just realized that I open sourced Intel’s implementation of the check if extension supported by the device or not with SPIR-V generator.

We added this list of options to clang::PreprocessorOptions and we enable only extensions that are passed to the clang from the run-time.

You can take a look at that approach at include\clang\Basic\LangOptions.h and include\clang\Lex\Preprocessor.h files.

This is alternative solution to the flags, but out implementation works only for extensions and online compilers.

I think we need sth like SupportedOpenCLExtensionsAndOptionalCoreFeatures in TargetInfo. Then we can let each target define supported OpenCL extensions and core features. Then we add SupportedOpenCLCoreFeatures to Sema based on TargetInfo, and use it to diagnose if unsupported OpenCL core features are used.

For SPIR target, we just enable all the extensions and optional core features since it is offline compiler.

Sam

I think TargetInfo is intended for features supported by HW, whereas OpenCL extensions and optional core features are defined by “OpenCL device”.

I think the question is whether Clang is able to decide whether an extension/feature is supported based on target (cpu, os, environment, etc.).

If we take a look at the extensions/optional core features:

OPENCLEXT(cl_khr_fp64)

OPENCLEXT(cl_khr_int64_base_atomics)

OPENCLEXT(cl_khr_int64_extended_atomics)

OPENCLEXT(cl_khr_fp16)

OPENCLEXT(cl_khr_gl_sharing)

OPENCLEXT(cl_khr_gl_event)

OPENCLEXT(cl_khr_d3d10_sharing)

OPENCLEXT(cl_khr_global_int32_base_atomics)

OPENCLEXT(cl_khr_global_int32_extended_atomics)

OPENCLEXT(cl_khr_local_int32_base_atomics)

OPENCLEXT(cl_khr_local_int32_extended_atomics)

OPENCLEXT(cl_khr_byte_addressable_store)

OPENCLEXT(cl_khr_3d_image_writes)

// OpenCL 2.0

OPENCLEXT(cl_khr_gl_msaa_sharing)

// Clang Extensions.

OPENCLEXT(cl_clang_storage_class_specifiers)

I think most of them can be determined by Clang based on target, e.g. fp64, fp16, atomics, byte_adderssable_store, 3d_image_writes since they are mostly hardware features.

I think gl_sharing, gl_event, d3d10_sharing do not matter since they have no effect on language/builtin functions.

gl_msaa_sharing should be judged only based on hardware capability, not the availability of gl, since that’s what matters to the builtin functions.

The advantage of this approach is to save the user the burden of setting command line options to turn on/off these extensions/features. For flexibility, we may also consider adding an option –fsupport-cl-ext:extension to allow turning on/off certain extensions/features.

Sam

I was trying to say that even if clang is able to decide whether some feature/extension is supported, we still need the option to disable that feature/extension in OpenCL (i.e. in clang too.)

Some other parts of OpenCL run-time might not be ready to support some features even if front-end compiler does e.g. built-in function for doubles are not implemented or back-end compiler doesn’t support ‘half’ data type.

In that case, you can set a default value in the target info and use command line options to suit the special case.

Also you may customize your target info for different branches depending on whether that extension is supported in that branch.

Sam