[cfe-dev] [OpenCL] atomic_double requires cl_khr_fp64 enabled

Fri Apr 22 10:29:25 PDT 2016

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

From: Bader, Alexey [mailto:alexey.bader at intel.com]
Sent: Friday, April 22, 2016 1:00 PM
To: Liu, Yaxun (Sam) <Yaxun.Liu at amd.com>; Anastasia Stulova <Anastasia.Stulova at arm.com>; cfe-dev (cfe-dev at lists.llvm.org) <cfe-dev at lists.llvm.org>
Cc: Sumner, Brian <Brian.Sumner at amd.com>; Pan, Xiuli <xiuli.pan at intel.com>; nd <nd at arm.com>
Subject: RE: [OpenCL] atomic_double requires cl_khr_fp64 enabled

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.

Thanks,
Alexey

From: Liu, Yaxun (Sam) [mailto:Yaxun.Liu at amd.com]
Sent: Friday, April 22, 2016 7:35 PM
To: Bader, Alexey; Anastasia Stulova; cfe-dev (cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>)
Cc: Sumner, Brian; Pan, Xiuli; nd
Subject: RE: [OpenCL] atomic_double requires cl_khr_fp64 enabled

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

From: Bader, Alexey [mailto:alexey.bader at intel.com]
Sent: Friday, April 22, 2016 12:00 PM
To: Liu, Yaxun (Sam) <Yaxun.Liu at amd.com<mailto:Yaxun.Liu at amd.com>>; Anastasia Stulova <Anastasia.Stulova at arm.com<mailto:Anastasia.Stulova at arm.com>>; cfe-dev (cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>) <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>>
Cc: Sumner, Brian <Brian.Sumner at amd.com<mailto:Brian.Sumner at amd.com>>; Pan, Xiuli <xiuli.pan at intel.com<mailto:xiuli.pan at intel.com>>; nd <nd at arm.com<mailto:nd at arm.com>>
Subject: RE: [OpenCL] atomic_double requires cl_khr_fp64 enabled

I think TargetInfo is intended for features supported by HW, whereas OpenCL extensions and optional core features are defined by "OpenCL device".
>From my experience I can say that some OpenCL implementations doesn't support extensions/features that available in HW.

Thanks,
Alexey

From: Liu, Yaxun (Sam) [mailto:Yaxun.Liu at amd.com]
Sent: Thursday, April 21, 2016 6:38 PM
To: Bader, Alexey; Anastasia Stulova; cfe-dev (cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>)
Cc: Sumner, Brian; Pan, Xiuli; nd
Subject: RE: [OpenCL] atomic_double requires cl_khr_fp64 enabled

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

From: Bader, Alexey [mailto:alexey.bader at intel.com]
Sent: Thursday, April 21, 2016 11:06 AM
To: Anastasia Stulova <Anastasia.Stulova at arm.com<mailto:Anastasia.Stulova at arm.com>>; Liu, Yaxun (Sam) <Yaxun.Liu at amd.com<mailto:Yaxun.Liu at amd.com>>; cfe-dev (cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>) <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>>
Cc: Sumner, Brian <Brian.Sumner at amd.com<mailto:Brian.Sumner at amd.com>>; Pan, Xiuli <xiuli.pan at intel.com<mailto:xiuli.pan at intel.com>>; nd <nd at arm.com<mailto:nd at arm.com>>
Subject: RE: [OpenCL] atomic_double requires cl_khr_fp64 enabled

> 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<https://github.com/KhronosGroup/SPIR/blob/spirv-1.0/include/clang/Basic/LangOptions.h#L142> and include\clang\Lex\Preprocessor.h<https://github.com/KhronosGroup/SPIR/blob/spirv-1.0/include/clang/Lex/Preprocessor.h#L504> files.
This is alternative solution to the flags, but out implementation works only for extensions and online compilers.

Thanks,
Alexey

From: Anastasia Stulova [mailto:Anastasia.Stulova at arm.com]
Sent: Thursday, April 21, 2016 1:47 PM
To: Bader, Alexey; Liu, Yaxun (Sam); cfe-dev (cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>)
Cc: Sumner, Brian; Pan, Xiuli; nd
Subject: RE: [OpenCL] atomic_double requires cl_khr_fp64 enabled

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

From: Bader, Alexey [mailto:alexey.bader at intel.com]
Sent: 20 April 2016 16:07
To: Liu, Yaxun (Sam); cfe-dev (cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>)
Cc: Anastasia Stulova; Sumner, Brian; Pan, Xiuli
Subject: RE: [OpenCL] atomic_double requires cl_khr_fp64 enabled

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?

Thanks,
Alexey

From: Liu, Yaxun (Sam) [mailto:Yaxun.Liu at amd.com]
Sent: Wednesday, April 20, 2016 6:03 PM
To: Bader, Alexey; cfe-dev (cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>)
Cc: 'anastasia.stulova at arm.com'; Sumner, Brian; Pan, Xiuli
Subject: RE: [OpenCL] atomic_double requires cl_khr_fp64 enabled

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

From: Liu, Yaxun (Sam)
Sent: Wednesday, April 20, 2016 11:00 AM
To: 'Bader, Alexey' <alexey.bader at intel.com<mailto:alexey.bader at intel.com>>; cfe-dev (cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>) <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>>
Cc: 'anastasia.stulova at arm.com' <anastasia.stulova at arm.com<mailto:anastasia.stulova at arm.com>>; Sumner, Brian <Brian.Sumner at amd.com<mailto:Brian.Sumner at amd.com>>; Pan, Xiuli <xiuli.pan at intel.com<mailto:xiuli.pan at intel.com>>
Subject: RE: [OpenCL] atomic_double requires cl_khr_fp64 enabled

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

From: Bader, Alexey [mailto:alexey.bader at intel.com]
Sent: Wednesday, April 20, 2016 10:56 AM
To: Liu, Yaxun (Sam) <Yaxun.Liu at amd.com<mailto:Yaxun.Liu at amd.com>>; cfe-dev (cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>) <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>>
Cc: 'anastasia.stulova at arm.com' <anastasia.stulova at arm.com<mailto:anastasia.stulova at arm.com>>; Sumner, Brian <Brian.Sumner at amd.com<mailto:Brian.Sumner at amd.com>>; Pan, Xiuli <xiuli.pan at intel.com<mailto:xiuli.pan at intel.com>>
Subject: RE: [OpenCL] atomic_double requires cl_khr_fp64 enabled

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

Thanks,
Alexey

From: Liu, Yaxun (Sam) [mailto:Yaxun.Liu at amd.com]
Sent: Wednesday, April 20, 2016 5:45 PM
To: cfe-dev (cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>)
Cc: 'anastasia.stulova at arm.com'; Sumner, Brian; Pan, Xiuli; Bader, Alexey
Subject: [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

--------------------------------------------------------------------
Joint Stock Company Intel A/O
Registered legal address: Krylatsky Hills Business Park,
17 Krylatskaya Str., Bldg 4, Moscow 121614,
Russian Federation

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

--------------------------------------------------------------------
Joint Stock Company Intel A/O
Registered legal address: Krylatsky Hills Business Park,
17 Krylatskaya Str., Bldg 4, Moscow 121614,
Russian Federation

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

--------------------------------------------------------------------
Joint Stock Company Intel A/O
Registered legal address: Krylatsky Hills Business Park,
17 Krylatskaya Str., Bldg 4, Moscow 121614,
Russian Federation

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

--------------------------------------------------------------------
Joint Stock Company Intel A/O
Registered legal address: Krylatsky Hills Business Park,
17 Krylatskaya Str., Bldg 4, Moscow 121614,
Russian Federation

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

--------------------------------------------------------------------
Joint Stock Company Intel A/O
Registered legal address: Krylatsky Hills Business Park,
17 Krylatskaya Str., Bldg 4, Moscow 121614,
Russian Federation

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160422/9ef7efa5/attachment.html>