This is an archive of the discontinued LLVM Phabricator instance.

[OpenCL] Undefine cl_intel_planar_yuv extension
ClosedPublic

Authored by sidorovd on Feb 26 2019, 3:26 AM.

Details

Summary

Consider the code:

#pragma OPENCL EXTENSION cl_intel_planar_yuv : begin
// some declarations
#pragma OPENCL EXTENSION cl_intel_planar_yuv : end

is enough for extension to become known for clang.

Remove unnecessary definition (otherwise the extension will be define where it's not supposed to be defined).

Diff Detail

Repository
rL LLVM

Event Timeline

sidorovd created this revision.Feb 26 2019, 3:26 AM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 26 2019, 3:26 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript
sidorovd updated this revision to Diff 188338.Feb 26 2019, 3:50 AM
Anastasia added inline comments.Feb 26 2019, 3:53 AM
test/SemaOpenCL/extension-begin.cl
26 ↗(On Diff #188332)

Can we also test that macro my_ext is not defined here but defined above?

It seems we are not testing anything like this...

sidorovd marked an inline comment as done.Feb 26 2019, 4:38 AM
sidorovd added inline comments.
test/SemaOpenCL/extension-begin.cl
26 ↗(On Diff #188332)

#pragma OPENCL EXTENSION my_ext : begin doesn't define an appropriate macro. And so cl-ext=+my_ext.

Anastasia added inline comments.Feb 27 2019, 9:57 AM
test/SemaOpenCL/extension-begin.cl
26 ↗(On Diff #188332)

But don't you need to expose the definition of it?

sidorovd marked an inline comment as done.Feb 27 2019, 11:46 AM
sidorovd added inline comments.
test/SemaOpenCL/extension-begin.cl
26 ↗(On Diff #188332)

Certainly I need, but now the only proper way to do so is by adding an extension via adding it in OpenCLExtensions.def. Previously we decided to avoid adding an extension directly into clang, so with a new approach I'd prefer not to add a definition of the macro in the header but define it somewhere else, otherwise the macro becomes defined where it's not supposed to be (even for ARM and AMD =) ).

Anastasia added inline comments.Feb 28 2019, 2:38 AM
test/SemaOpenCL/extension-begin.cl
26 ↗(On Diff #188332)

However, my understanding is that you should define the macro when you define the extension itself.

#pragma OPENCL EXTENSION my_ext : begin
#define my_ext
...
#pragma OPENCL EXTENSION my_ext : end

does it not work for you?

sidorovd marked an inline comment as done.Feb 28 2019, 3:50 AM
sidorovd added inline comments.
test/SemaOpenCL/extension-begin.cl
26 ↗(On Diff #188332)
#pragma OPENCL EXTENSION my_ext : begin
#define my_ext
...
#pragma OPENCL EXTENSION my_ext : end

^
I
It defines the macro regardless begin : end range, so one can consider that it's the same code as:

#define my_ext
#pragma OPENCL EXTENSION my_ext : begin
...
#pragma OPENCL EXTENSION my_ext : end

I agree, that it's a better way to define a macro with defining an appropriate extension itself, but it makes it be defined where it's not supposed to be (at least from my perspective).

To sum up:

  1. #pragma OPENCL EXTENSION my_ext : begin ... end - makes an extension known for clang if the header included and if the extension enabled; doesn't affect a macro definition anyhow;
  2. OPENCLEXT_INTERNAL(my_ext, *version*, ~0U) - makes an extension known for clang and defines an appropriate macro if the extension enabled.

I believe we are okay not to define cl_intel_planar_yuv macro in the header - just make the extension known for clang.

Anastasia accepted this revision.Mar 4 2019, 3:18 AM

LGTM! I am ok with this change to remove the macro from the common header. I don't think it belongs to there. However, I believe this functionality should be better represented in the vendors specific headers rather than clang directly. See my comment above!

test/SemaOpenCL/extension-begin.cl
26 ↗(On Diff #188332)

I believe we are okay not to define cl_intel_planar_yuv macro in the header - just make the extension known for clang.

We are not adding extensions to Clang unless they are needed for any internal functionality (i.e. to condition usage of half or double types that otherwise available in the standard C mode). If there is no special functionality needed then you should declare the macro in the header instead (probably the same place where you define the extension itself within begin/end to keep it clear). This is our official guidelines for vendor extensions currently.

This revision is now accepted and ready to land.Mar 4 2019, 3:18 AM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptJun 3 2019, 6:01 AM