[RFC][OpenCL] Allow users to add supported OpenCL extensions by pragma

Clang Frontend
1

Currently Clang defines supported OpenCL extensions for each target based on triple and CPU. As a default configuration this seems sufficient.

However if vendors and library developers want to add support of their own extensions, they have to modify Clang, which is very inconvenient.

We need a flexible and expressive way to add supported extensions for vendors and library developers.

Brian has a proposal which introduces a pragma to add supported extensions:

#pragma OPENCL EXTENSION the_new_extension_name : register

This pragma tells clang the name of a new OpenCL extension and request that it process it just like any other OpenCL extension, e.g. recognize

#pragma OPENCL EXTENSION the_new_extension_name : enable/disable

in subsequent code.

Since this pragma can be used in the header file of vendors or library developers' OpenCL implementations, it can provide flexible and expressive way to represent supported extensions when combined with other preprocessor constructs.

Any feedbacks? Thanks.

Sam

2

Interesting idea! Just to be clear, you are suggesting to add parsing of the following into Clang:

#pragma OPENCL EXTENSION the_new_extension_name : register

Which would add custom the_new_extension_name to the list of known and supported OpenCL extensions dynamically?

Normally, target triple that combines RT and specific hardware type would be used for those purposes.

But I believe it shouldn’t be too complicated to add this pragma considering that OpenCL already has similar ones.

This approach could offer some degree of flexibility to the library implementations,

which would otherwise have to add separate triple representing their library ABIs.

Would this be allowed in any OpenCL code as some sort of Clang extension or is there a plan to add this into Spec?

Thanks,

Anastasia

3

Hi Anastasia,

To answer your last question, this would be specific to clang. It will allow those of us using clang for OpenCL languages to implement many of our vendor specific extensions without any other changes to clang. I expect a few of the current KHR extensions that do not involve new or special types could be moved into opencl-c.h using this mechanism if desired as well.

Thanks,

Brian

4

Thanks, Brian!

Yes, perhaps we could try to make the extension list fully dynamic. Although I would imagine it’s still useful to have standard extensions from the Spec directly in Clang to be available for the cases without standard header include.

Cheers,

Anastasia

5

Hi,

Sorry for being late to the discussion, but I didn’t get the use case of the proposed feature.

Why vendor/library developer would need compiler to support for some pragma that doesn’t change to behavior of the compiler?

6

I don't care 2-ways about OpenCL, but adding non-standard pragma is a
slippery slope. Please don't add extensions because some vendor is
incapable of doing slight modifications to the source. If instead of a
pragma you offered a build configuration, macros or something else to
make this easier that I could totally understand.

7

Christopher, we can certainly modify clang, and have. But then we have to carry those modifications around and try to get them into the clang code base. Is it OK for clang to carry around every OpenCL vendor's vendor specific additions? AMD has quite a few extensions, and so do Intel, Qualcomm, and others. Wouldn't it be better for clang to provide a mechanism to allow extensions to be defined in a way that avoids clang having to carry around each and every one of those vendor extensions?

Alexey, this proposal does change the behavior of the compiler. It informs clang that there is an OpenCL extension that can be enabled and disabled whose name was not known at the time clang was built. After being registered, clang must process enable and disable pragmas for the new extension exactly as it does the built-in KHR extensions.

Brian

8

Hi All,

FYI. A patch has been submitted for review: http://reviews.llvm.org/D21698

Sam

9

I think this is two questions and I'm no authority on OpenCL, but my
general views

1) Should clang accept vendor specific extensions - Not my call, but I
think if they are generally valuable to the community - why not

2) Should the clang codebase be designed in a way to accommodate
vendor extensions.. Current proposal is to add a directive, is there
another way to accomplish this?

Could all this be refactored into something that would fit into a header?
Make a directory called OpenCL/extensions/<vendor>ocl.hpp

This could get complicated if Vendor A's extensions conflict with
Vendor B's.. There's also the case of common extensions that could be
aliased..

10

Hi Brian,

Alexey, this proposal does change the behavior of the compiler. It informs clang that there is an OpenCL extension that can be enabled and disabled whose name was not known at the time clang was built. After being registered, clang must process enable and disable pragmas for the new extension exactly as it does the built-in KHR extensions.

What I meant is that I don't quite understand how it's useful developers. Clang is supposed to check for errors and produce LLVM IR for the back-end.

The only value I see that this registering allows developers use "#pragma ... enable" and suppress clang's warning about unsupported extension. But since clang doesn't provide any additional error checking for the registered extension nor produce different LLVM IR, I don't see any reason to use "#pragma ... enable" in the first place. As an alternative solution we can introduce a compiler knob that will disable this diagnostics.

My understanding is that the only useful OpenCL extension supported by clang are 'cl_khr_fp16', 'cl_khr_fp64' and 'cl_khr_*_atomics', since they enable compilation of half/double/atomic types. The rest are useless for the front-end compiler. If developer enable 'cl_khr_gl_sharing' in the OpenCL program - it will have zero effect on compilation results.

I don't this it's required to have compiler directive for every OpenCL extension. It makes sense to have compiler directive only for extensions that modify OpenCL kernel language semantics.

Thanks,
Alexey

11

I don't this it's required to have compiler directive for every OpenCL extension. It makes sense to have compiler directive only for extensions that modify OpenCL kernel language semantics.

I agree with you here, but I guess it's mainly required for compatibility reasons although most of vendors use Clang anyways. But yes, some extensions from the Spec don't seem to be useful for compiler indeed. Wondering if it should be discussed with Khronos?

Anastasia

12

Sorry for the delayed response.

If an OpenCL extension defines types and builtin functions. When this extension is disabled, we should diagnose the use of such types and builtin functions. If we did not do that already, that means our diagnostics need to be improved.

If we want to implement that purely in the compiler, we need to define the types and builtin functions of all extensions in Clang. As we know there are some limitations in the types that can be used in the builtin td file, so most likely these builtin functions definitions need to be added programmatically in Clang, which is a lengthy and error-prone process, and definitely not friendly to the library developers.

This justifies a better way to define the OpenCL extension and its associated types and builtin functions.

For certain types and builtin functions which require special semantics, implementation in Clang itself is unavoidable. However, for most extensions, probably we only need to diagnose the availability of the types and builtin functions associated with an extension, whereas the types and builtin functions themselves do not need special diagnostics. In such case defining them in Clang programmatically is unnecessary. We only need to have a way to tell Clang that these types and builtin functions are associated with an OpenCL extension.

Since these types and builtin functions are defined in header files, so naturally we can use pragma to do that.

I propose a modification of the previous proposal which allows us to associate types and function declarations with an OpenCL extension, e.g.

#pragma OpenCL EXTENSION new_extension : begin optional_available_opencl_version

Typedef global struct type1;
Void func1();
Void func2();

#pragma OpenCL EXTENSION new_extension : end

Basically the types and builtin functions defined between #pragma OpenCL EXTENSION name : begin and #pragma OpenCL EXTENSION name : end associates with the extension so that we can diagnose invalid uses of them.

I also added an optional argument for the pragma to indicate the earliest available OpenCL version of this extension so that we can diagnose incompatible OpenCL version for the extension.

Sam

13

Hi Sam,

Could preprocessor be utilized to diagnose invalid use of such extensions?

For instance, library developer would implement library header with the following code:

#ifdef cl_vendor_new_extension

typedef global struct type1;
void func1();
void func2();

#endif

User is required to pass -Dcl_vendor_new_extension if the intension is to use new extension.
If define is not set, but type1 or func1/func2 are present in the code - clang will report errors.

Thanks,
Alexey

14

It may not be a good idea since users may want to use #ifdef cl_vendor_new_extension to condition their own code.

Sam

15

If the concern is that using `#pragma OPENCL EXTENSION name : begin` may pollute the original OPENCL EXTENSION pragma. How about

#pragma clang_opencl_extension name : begin version
#pragma clang_opencl_extension name : end

And we can put this feature under an OpenCL extension clang_opencl_extension and disabled by default, so only those who enables it can use these pragmas.

Sam

16

Hi Sam,

I think we can use macro to enable new types and built-in function that doesn't require native support by clang.

Here is quote from OpenCL extension specification (page 9):

Every extension which affects the OpenCL language semantics, syntax or adds built-in functions to the language must create a preprocessor #define that matches the extension name string.
This #define would be available in the language if and only if the extension is supported on a given implementation.

Example:
An extension which adds the extension string "cl_khr_3d_image_writes" should also add a preprocessor #define called cl_khr_3d_image_writes. A kernel can now use this preprocessor #define to do something like:

#ifdef cl_khr_3d_image_writes
    // do something using the extension
#else
   // do something else or #error!
#endif

So there should be no problem for users to use #ifdef cl_vendor_new_extension to condition their own code.

What benefits do you see in using pragma instead of preprocessing directives?

Thanks,
Alexey

17

Hi Alexey,

The issue of using #ifdef cl_khr_3d_image_writes to define builtin functions associated with extension cl_khr_3d_image_writes is that we cannot disable them when #pragma OPENCL EXTENSION cl_khr_3d_image_writes : disable is used.

Let's say there is a builtin function builtin_foo() associated with extension cl_khr_foo. The macro cl_khr_foo is defined if the extension is supported. It is still defined even after #pragma OPENCL EXTENSION cl_khr_3d_image_writes : disable is used.

For example,

// cl_khr_foo is defined if extension cl_khr_foo is supported
#ifdef cl_khr_foo
  builtin_foo(); // library header defining the builtin function
#endif

#ifdef cl_khr_foo
  foo(); // user's code using cl_khr_foo
#endif

#pragma OPENCL EXTENSION cl_khr_foo : disable
builtin_foo(); // expected-warning{{builtin function foo() is only available with extension cl_khr_foo enabled}}
foo(); // should have no warning

We won't get the expected warning msg.

However if we use a specific pragma to enclose the builtin function definitions for the extension, we will be able to emit the warning msg.

Sam

18

Re-send to clean up the format.

19

Hi Sam,

  // cl_khr_foo is defined if extension cl_khr_foo is supported
  #ifdef cl_khr_foo
  builtin_foo(); // library header defining the builtin function
  #endif

  #ifdef cl_khr_foo
   foo(); // user's code using cl_khr_foo
  #endif

  #pragma OPENCL EXTENSION cl_khr_foo : disable
   builtin_foo(); // expected-warning{{builtin function foo() is only available with extension cl_khr_foo enabled}}
  foo(); // should have no warning

I'm not sure I understand the expected results.
I would expect errors on using unavailable functionality instead of warning. Another question is how OpenCL driver should behave in case of using 'foo' with disabled extension.
Does the proposed implementation (http://reviews.llvm.org/D21698) work like described in the comments?

I was trying to implement something like this for supported extensions cl_khr_fp16/ cl_khr_fp64 before, but it's not easy if related declaration was parsed.
Here is one of the issues I faced. Let's say we compile the following kernel for the device that supports both extensions.

kernel k() {
  #pragma OPENCL EXTENSION cl_khr_fp16 : disable
  float f = min(1, 2); // ambiguous call
}

ambiguous call: at this point there should be at least two acceptable declarations float min(float, float) and double min(double, double) (let's .
But actually clang will report half min(half, half) also, since it was parsed to AST, available to clang and meet overload candidate requirements.
This is one of the issues that should be fixed to make #pragma OPENCL EXTENSION reasonable.

Thanks,
Alexey

20

Hi Alexey,

My comments are below.

Sam