[OpenCL] Define OpenCL feature macros for all versions

[azabaznov]

Summary

This change relates to OpenCL C 3.0 support. RFC thread: https://lists.llvm.org/pipermail/cfe-dev/2020-September/066883.html

The same interface ('-cl-ext' option) is being used to indicate that feature or extension is supported. OpenCL C 3.0 by default doesn't provide any features which are core in OpenCL C 2.0. The idea is to define feature test macros for all OpenCL versions and provide simultaneous macro presence if there exist equivalent extension.

[Anastasia]

I guess targets like SPIR will be supporting all features by default?

At this point, I would prefer that we only add the features that affect the parsing directly i.e. used in the clang source code.

FYI I think we need to explain the common design of features and extensions in comments and some code renaming somehow. But I am not clear yet and especially that it is likely some more refactoring will take place. Let's think about this in the meantime.

clang/include/clang/Basic/OpenCLExtensions.def

137

Does this need to be in the frontend?

148

if we are not going to change clang to make int64 conditional I would suggest we don't add this here for now.

clang/include/clang/Basic/OpenCLOptions.h

123–136

I guess we need to make sure that targets can't conditionally support features in OpenCL 2.0 or earlier standards.

clang/lib/Frontend/CompilerInstance.cpp

950 ↗

(On Diff #299629)

Would it be possible to move this into getTarget().adjust(getLangOpts()) just below. There is a FIXME that explains that we should be doing such adjustment differently but we haven't solved it with time so let's keep the flow as is for now.

clang/test/Preprocessor/opencl-feature-extension-simult.cl

15 ↗

(On Diff #299629)

Is this a typo?

all__opencl_c_fp64

[Anastasia]

PS I think it's better to move both test files to SemaOpenCL folder as they are not related to common parsing but OpenCL specifically.

[azabaznov]

I guess targets like SPIR will be supporting all features by default?

It sounds confusing for me: can you please elaborate about why does SPIR-V target should support all features/extension by default? If we are compiling OpenCL C 3.0 with optional functionality we most likely want to get an error in FE level if some functionality is not supported by the target, but not in BE after SPIR-V translation.

clang/include/clang/Basic/OpenCLExtensions.def

137

I can remove features which affect only header from this file. But in this case we need to extend '-cl-ext' to register unknown features/extensions (http://lists.llvm.org/pipermail/cfe-dev/2020-October/066932.html). I think this option functionality extending should be done in a separate commit, so we can keep this kind of features here at least for now. What do you think?

148

Yes, that sounds reasonable to be.

clang/include/clang/Basic/OpenCLOptions.h

123–136

This can be done by adding a new method TargetInfo::setSupportedOpenCL30Features() which can be called in ::adjust, does this make sense? I believe now current options setting (TargetInfo::setSupportedOpenCLOpts()) knows nothing about OpenCL version which.

clang/lib/Frontend/CompilerInstance.cpp

950 ↗

(On Diff #299629)

Yeah, this can be moved there. Btw a lot of OpenCL C 3.0 options setting will take place in ::adjust...

clang/test/Preprocessor/opencl-feature-extension-simult.cl

15 ↗

(On Diff #299629)

Ah, yeah, thanks, Will definitely change that.

[Anastasia]

In D89869#2378235, @azabaznov wrote:

I guess targets like SPIR will be supporting all features by default?

It sounds confusing for me: can you please elaborate about why does SPIR-V target should support all features/extension by default? If we are compiling OpenCL C 3.0 with optional functionality we most likely want to get an error in FE level if some functionality is not supported by the target, but not in BE after SPIR-V translation.

SPIR is a special abstract target that doesn't bind to any specific architecture. It is used in different ways but primarily to generate portable IR that can be loaded in toolchains for different vendors. It therefore normally allows all extensions and features to be compiled because the limitations of actualy target are not known at the point of compilation for SPIR. As a matter of fact if you check how extensions are implemented they are typically supported for SPIR.

FYI SPIR is being reused for SPIR-V translation but it is not the only use case.

What did you think in mind regarding activation of features for SPIR?

[Anastasia]

clang/include/clang/Basic/OpenCLExtensions.def

137

Yes, absolutely let's focus on frontend only features for now. I hope we will clarify what we do with the rest in the next few weeks.

clang/include/clang/Basic/OpenCLOptions.h

123–136

I would prefer to use one method for both. We could check the OpenCL version before invoking this or extend it with LangOpts param? Although on second thought since we are going this route of adding features into earlier standards we could just allow targets to configure in a way they like. i.e. with no extra checking per version allowing more flexibility if they don't need to worry about being stricktly conformant... as soon as it doesn't generate an integrity issue for old standards...

[azabaznov]

Addressed all concerns except replacing __opencl_c_int64 definition into header. The reason for this as follows: this macro should be predefined regardless if clang includes default header or not.

[azabaznov]

What did you think in mind regarding activation of features for SPIR?

I don't see any difference between extensions and features in that case (at least for now), so in the latest patch x86 and spir targets will define all the features.

[Anastasia]

In D89869#2388499, @azabaznov wrote:

Addressed all concerns except replacing __opencl_c_int64 definition into header. The reason for this as follows: this macro should be predefined regardless if clang includes default header or not.

FYI clang doesn't provide full support of OpenCL without the header. In fact, there is ongoing work on making the header included by default without any flag. But I can see that this functionality is related to the frontend and not something that is simply added via libraries so I don't have strong objections for adding it in the clang source code. However, the macro can be added without registering the new extension (see how __IMAGE_SUPPORT__ is added for example). Right now you are adding a pragma and a target setting that targets can modify without any effect, so I would like to avoid these.

My preference would be if you prepare a separate patch for this. Smaller selfcontained patches are easier and faster to review and also it reduces gaps in testing.

clang/include/clang/Basic/OpenCLExtensions.def

135

Btw I guess we don't need the last parameter for the features since it's always 0?

144

I am thinking maybe we could add an extra parameter where we can specify the extension it is aliased to:

OPENCLFEAT_INTERNAL(__opencl_c_fp64, 120, ~0U, cl_khr_fp64)

Then it makes clearer which features correspond to which extensions and you can populate EquivalentFeaturesExtensions from this field? Moreover, you can then even make a map of references to OpenCLOptions::Info so you don't need to look them up from the name every time.

The drawback is that we need an extra parameter that is mainly empty... however we could recycle the last parameter that is always 0 right now.

clang/include/clang/Basic/OpenCLOptions.h

25

Ok, let's add spec reference where the feature is described so something like:
OpenCL 3.0 s6.2.1

35

Ok, I see why you are adding this field but I am not very happy with it. However, if you prefer to keep it I suggest to add a comment otherwise it is mislediang because ideally in Clang we should be using versions from the LangOpts everywhere. Alternatively we could consider a helper function to calculate the version although it doesn't eliminate the need to the comment.

36

I don't see a value in such field. We can simply check LangOpts::OpenCLCPlusPlus.

39

I feel I missed that. Can you explain why it is not the same. Any spec reference would be help.

46

I find this bit hard to read (if there is such extension, otherwise check specific version of feature) how about:

Set features for OpenCL C prior to 3.0 based on either:
 - the equivalent extension
 - or language version.

48

I find the name of this function very confusing but I can't think of any better one. Also the flow is becoming harder to understand to be honest. This function is not as straight forward as support because it might not actually do what is expected from it. I wonder if the name with something like adjust would be more appropriate. At the same time adjustFeatures is the only place where we need to check for the version. Perhaps you can just do the language version check straight in adjustFeatures?

Overall, let's just get clear about the flow of setting the features and extensions. If in adjustFeatures we set default features supported in a certain language version then targets can set the other features. Now let's examine what should happen with the features and extensions on the following use cases:

• Do we always set the equivalent extension when the feature is being set by the target?
• Do we always set the equivalent feature when the extension is being set by the target?
• What happens when equivalent features and extensions are set but to different values?
• What if targets set core feature/extension to unsupported?
• How does -cl-ext modify core features/extensions and equivalent features+extensions?

I am a bit worried about the fact that we have different items for the same optional functionality in OpenCLOptions as it might be a nightmare to keep them consistent. We can however also choose a path of not keeping them consistent in the common code and rely on targets to set them up correctly.

Initially, when we discussed adding feature macros to earlier standards I was thinking of simplifying the design. For example instead of checking for extension macros and feature macros in the header when declaring certain functions we could only check for one of those. The question whether we can really achieve the simplifications and at what cost.

49

I think the message should be
Can't be called for OpenCL C 3.0 or higher

52

If On is true but the extension is unsupported then the feature will also stay unsupported despite of the value of On. This might be a bit surprising though.

85–86

I guess this comment should now go to setOpenCLVersion. The same for the function below.

153

This is true apart from subgroups btw.

154

How about adjustFeaturesPerOpenCLVersion

160

I think it's clearer if this is done while setting the extensions i.e. perhaps we can add a helper supportExtenions

164

how about:
For OpenCL C 3.0 all features are to be set by the targets explicitly.

clang/lib/Frontend/CompilerInstance.cpp

954 ↗

(On Diff #304493)

I think this block better belongs to getTarget().adjust(getLangOpts()) too, otherwise we end up doing many similar steps scattered all over.

clang/lib/Frontend/InitPreprocessor.cpp

1119

If you would like to add predefined macro for __opencl_c_int64, then this is a good place.

clang/lib/Parse/ParsePragma.cpp

789

I think here you should check for whether it is a feature and if so the pragma is ignored with a warning.

We probably should add a test for pragmas too.

clang/lib/Sema/Sema.cpp

295

I think the version here should already have been set in CompilerInstance.cpp? Perhaps we could even set it in the constructor of OpenCLOptions, otherwise, there is a little value in setting this field if we end up calling this helper multiple times instead of passing LangOpts into the original member function.

[Anastasia]

In D89869#2392032, @Anastasia wrote:

In D89869#2388499, @azabaznov wrote:

Addressed all concerns except replacing __opencl_c_int64 definition into header. The reason for this as follows: this macro should be predefined regardless if clang includes default header or not.

FYI clang doesn't provide full support of OpenCL without the header. In fact, there is ongoing work on making the header included by default without any flag. But I can see that this functionality is related to the frontend and not something that is simply added via libraries so I don't have strong objections for adding it in the clang source code. However, the macro can be added without registering the new extension (see how __IMAGE_SUPPORT__ is added for example). Right now you are adding a pragma and a target setting that targets can modify without any effect, so I would like to avoid these.

My preference would be if you prepare a separate patch for this. Smaller selfcontained patches are easier and faster to review and also it reduces gaps in testing.

FYI I have added __opencl_c_int64 in my patch https://reviews.llvm.org/D91531 mainly for the demonstration purposed as it is an RFC patch I am not sure when this will be committed. In case you prefer to commit this earlier I will rebase my change if necessary.

[azabaznov]

clang/include/clang/Basic/OpenCLExtensions.def

135

This need to be restructured at all, now I just wanted to be consistent. I think there was wrong interpretation of "core extension" concept. Core means nothing more than it was just promoted to core specification, not supported by default starting from specific OpenCL version. Am I missing something in the spec? However, I'm not sure if we need to reimplement this to maintain backward compatibility... Anyway, I'll try to remove it from features.

144

OPENCLFEAT_INTERNAL(__opencl_c_fp64, 120, ~0U, cl_khr_fp64)

Yes, that's sound reasonable to me

The drawback is that we need an extra parameter that is mainly empty

I don't think we need to keep it OpenCLOptions::Info, we can always this from OpenCLOptions.

clang/include/clang/Basic/OpenCLOptions.h

35

However, if you prefer to keep it I suggest to add a comment otherwise it is mislediang because ideally in Clang we should be using versions from the LangOpts everywhere

The reason for this is that LangOptions is not always available for proper settings. So this just needed internally. Also, we could add TargetInfo::setOpenCLOptions(const LangOptions &Opts) where we can set all extensions/features in one step (invoke ::setSupportedOpenCLOpts and ::setOpenCLExtensionOpts) to make sure OpenCLOptions will get proper OpenCL version. What do you think of that?

39

Ah, yeah. This one is confusing.

You can check 4.2. Querying Devices, the CL_DEVICE_SUB_GROUP_INDEPENDENT_FORWARD_PROGRESS entry:

This query must return CL_TRUE for devices that support the cl_khr_subgroups extension, and must return CL_FALSE for devices that do not support subgroup.

It was missing before OpenCL C 2.1 and subgroup independent forward progress is optional in 2.1 and 3.0. Agree that spec is not clear here though. This is just the case when feature describes more functionality than the extension.

48

Ok.

Now I think that defining features for pre-OpenCL C 3.0 if they have equivalent extension indeed brings up some complexities. The check for the support of features in header will still look like follows:

#if defined(cl_khr_fp64) || defined(__opencl_c_fp64)
...
#endif

so there is no need to add a feature macro for pre-OpenCL C 3.0 if there is a same extension to check. Are you agree with that?

However, I still see a reason for defining equivalent extension for OpenCL C 3.0 if feature is supported (backward compatibility with earlier OpenCL C kernels).

Overall, let's just get clear about the flow of setting the features and extensions

IMO the main thing which we need to try to follow here is that features are stronger concept than extensions in OpenCL C 3.0. The reason for this is that API won't report extension support if the feature is not supported (3d image writes example. To be clear, if users need to support functionality in OpenCL C 3.0 they should use features, for earlier versions they should use extensions.

Answering your questions:

Do we always set the equivalent extension when the feature is being set by the target?

I think we should do it for OpenCL C 3.0 only to maintain backward compatibility with OpenCL C 1.2 applications.

Do we always set the equivalent feature when the extension is being set by the target

I think we shouldn't set equivalent feature for pre-OpenCL C 3.0 since there is no need in that. This brings up some complexities, and we can check an extension presence.

What happens when equivalent features and extensions are set but to different values

We need to avoid that case for OpenCL C 3.0 since implementation could not report extension support if equivalent feature is not supported.

How does -cl-ext modify core features/extensions and equivalent features+extensions

'-сl-ext' should not affect feature support in pre-OpenCL 3.0. In OpenCL C 3.0 it's more likely to use features instead of extensions since it's a stronger concept; and equivalent feature+extension will be supported simultaneously if feature is turned on.

And a question:

What if targets set core feature/extension to unsupported?

Not sure what do you mean about core here. What do you mean? But I don't think this will cause a problem if we will follow up the rules that I described above. Do you see any?

52

Ah, yeah... I'll double check that and will try to avoid that case. Thanks.

clang/lib/Parse/ParsePragma.cpp

789

Sure, this is part of my plans. I just wanted to separate into another patch because features are not handled in clang at all for now.

clang/lib/Sema/Sema.cpp

295

It may be confusing but now we are using two different OpenCLOptions instances. One in TargetOptions (here) and one in Sema( and here). Not sure why it's not just a reference in Sema... Anyway, passing LangOptions into ctor is not possible at least for now. I would prefer to keep a reference to OpenCLOptions in Sema. I was also thinking about unifying with target features (like here) and handle OpenCL features/extensions in some similar manners. But I think this a long term one and relates more to a refactoring.

[Anastasia]

clang/include/clang/Basic/OpenCLExtensions.def

135

This need to be restructured at all, now I just wanted to be consistent. I think there was wrong interpretation of "core extension" concept. Core means nothing more than it was just promoted to core specification, not supported by default starting from specific OpenCL version.

Good question! I don't think spec ever explained what it means. This is possibly one of multiple interpretations and it won't be easy to change but it would help if spec clarifies it. Potentially we can point out the interpretation from clang implementation. Perhaps it will be taken into account.

clang/include/clang/Basic/OpenCLOptions.h

35

Yes this feels neater!

48

Now I think that defining features for pre-OpenCL C 3.0 if they have equivalent extension indeed brings up some complexities. The check for the support of features in header will still look like follows:

#if defined(cl_khr_fp64) || defined(__opencl_c_fp64)
...
#endif

so there is no need to add a feature macro for pre-OpenCL C 3.0 if there is a same extension to check. Are you agree with that?

Yes, we could still simplify the headers by adding the feature macros directly there:

#if defined(cl_khr_fp64)
#define __opencl_c_fp64 1
#endif
...
#if defined(__opencl_c_fp64)
double cos(double);
...
#endif

Answering your questions:

Do we always set the equivalent extension when the feature is being set by the target?

I think we should do it for OpenCL C 3.0 only to maintain backward compatibility with OpenCL C 1.2 applications.

Do we always set the equivalent feature when the extension is being set by the target

I think we shouldn't set equivalent feature for pre-OpenCL C 3.0 since there is no need in that. This brings up some complexities, and we can check an extension presence.

What happens when equivalent features and extensions are set but to different values

We need to avoid that case for OpenCL C 3.0 since implementation could not report extension support if equivalent feature is not supported.

How does -cl-ext modify core features/extensions and equivalent features+extensions

'-сl-ext' should not affect feature support in pre-OpenCL 3.0. In OpenCL C 3.0 it's more likely to use features instead of extensions since it's a stronger concept; and equivalent feature+extension will be supported simultaneously if feature is turned on.

Ok, this all makes sense. The only question is whether you plan to keep coherency between corresponding features and extensions automatically or it has to be done manually i.e. targets would be responsible to provide the setup consistently and the same applies to values set in -cl-ext e.g. if it has +cl_khr_fp64 then it should also have +__opencl_c_fp64. The advantage of doing it automatically is that it reduces the risks of errors, but it might become complicated to implement and test all possible combinations.

What if targets set core feature/extension to unsupported?

Not sure what do you mean about core here. What do you mean? But I don't think this will cause a problem if we will follow up the rules that I described above. Do you see any?

I think right now it only applies to extensions actually. What I mean is if a target sets the extension which is core to unsupported, but I think this was intended to be allowed... it is not explicitly explained in the spec.

clang/lib/Parse/ParsePragma.cpp

789

Ok, this makes sense since OpenCL 3.0 is experimental in upstream clang so nobody should be using it in production content until it's officially released.

clang/lib/Sema/Sema.cpp

295

It may be confusing but now we are using two different OpenCLOptions instances. One in TargetOptions (here) and one in Sema( and here). Not sure why it's not just a reference in Sema...

Yes I agree, having this duplicated seems incorrect. I think one should be a reference indeed.

Anyway, passing LangOptions into ctor is not possible at least for now. I would prefer to keep a reference to OpenCLOptions in Sema. I was also thinking about unifying with target features (like here) and handle OpenCL features/extensions in some similar manners. But I think this a long term one and relates more to a refactoring.

Generally, OpenCL features/extensions are somewhat conceptually in the middle - between LangOpts and target features, mainly because target features are intended for one family of architectures while OpenCL features can be supported by multiple very different devices. However, I agree they might be better implemented using the regular target features. If you are planning to look into it at some point I am interested to discuss your ideas in more details.

[azabaznov]

clang/include/clang/Basic/OpenCLOptions.h

48

Ok, this all makes sense. The only question is whether you plan to keep coherency between corresponding features and extensions automatically or it has to be done manually

I think it's possible to handle these in our OpenCLOptions, e.g. automatically. This will release targets from obligations to take of this simultaneous setting: each target will need to duplicate this (introduce helper...?). For now I think it's possible to reuse setSupportedOpenCLOpt for extensions and features.

I think right now it only applies to extensions actually. What I mean is if a target sets the extension which is core to unsupported

This shouldn't affect anything if feature unsupported. Just to double check, you mean target calls:

support("-cl_khr_fp64");
support("+__opencl_c_fp64");

As I see it compiler should define both macros both for OpenCL C 3.0 and nothing for fp64 in earlier versions.

P.S. actually I didn't find something similar about fp64 as for 3d images in API reports. I'm wondering if spec is missing that for fp64, or is something similar to subgroups, and extension/feature are not the same....

[Anastasia]

clang/include/clang/Basic/OpenCLOptions.h

48

P.S. actually I didn't find something similar about fp64 as for 3d images in API reports. I'm wondering if spec is missing that for fp64, or is something similar to subgroups, and extension/feature are not the same....

Yes, potentially we need to brush up the spec a bit more for extensions and features that are inherited from extensions. I find the spec very inconsistent. In some cases it is not even clear what extensions even mean. Here is one example: https://www.khronos.org/registry/OpenCL/sdk/2.2/docs/man/html/cl_khr_depth_images.html

Not sure what's the best approach as it's a lot of work. Potentially we should create spec issues as we go along with the implementation. I think perhaps we should expand section 6.2.2. to at least explain what the optional core extension actually means?

[azabaznov]

Addressed almost all technical and cosmetic concerns. Except putting reference of OpenCLOptions in Sema due to const of TargetInfo. I am going to think about that later. Also:

1. Added new target method to define extensions/features macros in one step (target settings + option)
2. Define generic address space macro if pipes or device enqueue is supported.
3. Did some minor refactoring of OpenCLOptions.h and OpenCLExtensions.def.

[Anastasia]

After a recent discussion with Khronos on https://github.com/KhronosGroup/OpenCL-Docs/issues/500 and more thinking I start to realize that there is absolutely nothing new in OpenCL 3.0 features as it isn't a new concept at all. They use to be explained as optional core features in the extension spec from early spec versions. So I think what have changed mainly in OpenCL 3.0 is that the features that were core have now become optional while the current design in clang assumes that core features can't become optional. I feel this is what we should reflect better in the design right now. So the categories we have are:

• extension (conditionally supported, can have pragma to alter certain functionality)
• optional feature (conditionally supported, pragma has no effect)
• core feature (unconditionally supported, pragma has no effect)

Then for every pair of optional functionality and OpenCL language version one of the above categories should be set.

Let's take cl_khr_3d_image_writes/__opencl_c_3d_image_writes as an example:

• In OpenCL C 1.0-1.2 it is an extension
• In OpenCL C 2.0 it is a core feature
• In OpenCL C 3.0 it is an optional feature

I am now trying to think perhaps the data structure in OpenCLOptions should be changed to better match the concept. Then perhaps the flow will become more clear? Right now I find it very complex to understand, mainly because there are features that are being set differently before and after OpenCL 3.0 and then overridden in some places or not set to the expected values. It also doesn't help of course that there are so many existing bugs like with the core features...

I didn't want to end up with a big refactoring from this patch but now I start to think that considering the situation it might be unavoidable. :(

clang/include/clang/Basic/OpenCLOptions.h

35

I feel this just results in more layering violations than we have already made in the past. The version should really be stored in the LangOpts and we can either have a reference to it here or/and a helper function to compute the lang version equivalent for the extensions given LangOpts.

Perhaps this relates to the fact that OpenCLOptions are completely duplicated in Sema... maybe they should have just been there and not in the target settings after all... Or perhaps we are in need for some bigger restructuring in order to avoid making more mess...

42

I think the comment is misleading a bit because you have a condition on OpenCL version.

128

This is a violation of the API, as its expected to set the feature to a certain value` V`, but here it is forced to be true.

Perhaps a better way to handle this is to define whether the feature is core or not and then skip over core features here.

The OpenCL 3.0 features will be defined as core in OpenCL 2.0 but optional in OpenCL 3.0.

Then we can update the API with a more consistent and clear behavior.

133

We really need to follow up with some clean up of the duplication and the need to copy entries over.

clang/include/clang/Basic/TargetInfo.h

1488

I think the interface is becoming unclear too many members with similar functionality...

clang/lib/Basic/TargetInfo.cpp

359

Can you explain the reason for this change? I think the meaning of adjust function is to override something that was previously set. So I think normal initialization shouldn't really go here.

clang/lib/Headers/opencl-c-base.h

12

for pre-OpenCL -> before

[Anastasia]

clang/include/clang/Basic/OpenCLOptions.h

35

FYI, I looked at the duplication of OpenCLOptions in Sema and TargetInfo, and my conclusion is that the reason why it was copied to Sema is that TargetInfo is expected to be immutable throughout the parsing, which makes sense because parsing source shouldn't modify the target being compiled for.

The reason why OpenCLOptions need to be modified is to set the Enable value when pragma is being parsed. This should have been separated to Sema and the rest would have stayed as a part of the TargetInfo. In reality, most of pragmas are useless so we don't even need to set anything for them aside from perhaps fp64. I am planning to remove most of them but it will take some time.

Now there is another obstacle - serialization to/from PCH, that now sets OpenCLOptions of the Sema. I don't think this should have been done this way because it seems bizarre to me that extensions are being overridden after importing PCH module. The implementation was done for the internal header use case but if any customer PCH is imported the flow would break. I don't have a solution to this one yet, but it is clear that this violates the standard PCH flow where the target configuration should be checked to match exactly the configuration being compiled for and if they don't match the import should fail. There should be no overriding of target settings by the PCH import. This will be trickier to fix.

[azabaznov]

I didn't want to end up with a big refactoring from this patch but now I start to think that considering the situation it might be unavoidable. :(

Well, it was expected. However, I didn't want to mess this refactoring with OpenCL C 3.0 support at first.

I already do have some progress in this direction: https://reviews.llvm.org/D92277. We can differentiate between core and optional features by the defining them appropriately in OpenCLExtensions.def. Note that this also removes duplication of OpenCLOptions so we can query all features/extensions from TargetInfo directly. This will also allow simplifying OpenCLOptions in future

[azabaznov]

Due to refactoring in https://reviews.llvm.org/D92277 this flow is no longer valid. New patch for this functionality is here: https://reviews.llvm.org/D95776.

clang/include/clang/Basic/OpenCLExtensions.def

 //===--- OpenCLExtensions.def - OpenCL extension list -----------*- C++ -*-===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
 // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 //===----------------------------------------------------------------------===//
 //
 // This file defines the list of supported OpenCL extensions.
 //
 //===----------------------------------------------------------------------===//
 
-// Macro OPENCLEXT or OPENCLEXT_INTERNAL can be defined to enumerate the
+// Macro OPENCLEXT or OPENCLCOREEXT_INTERNAL can be defined to enumerate the
 // OpenCL extensions listed in this file.
 //
 // If the extensions are to be enumerated without the supported OpenCL version,
 // define OPENCLEXT(ext) where ext is the name of the extension.
 //
 // If the extensions are to be enumerated with supported OpenCL version,
-// define OPENCLEXT_INTERNAL(ext, avail, core) where
+// define OPENCLCOREEXT_INTERNAL(ext, avail, core) where
 //   ext - name of the extension or optional core feature.
 //   avail - minimum OpenCL version supporting it.
 //   core - minimum OpenCL version when the extension becomes optional core
 //          feature or core feature. ~0U indicates not a core feature or an
 //          optional core feature.
 //
+// For OpenCL C 3.0 features,
+// define OPENCLFEAT_INTERNAL(feat, avail, samext)
+//    feat - name of the feature.
+//    avail - minimum OpenCL version supporting it with no availability
+//            for compiler to disable it for OpenCL C less than 3.0.
+//    sameext - extension which is equivalent to a given feature
+//
 // As per The OpenCL Extension Specification, Section 1.2, in this file, an
 // extension is defined if and only it either:
 //  * affects the OpenCL language semantics or its syntax,
 //  * adds built-in functions to the language.
 //
 // For such an extension, a preprocessor #define that matches the extension
 // name must be created and a #pragma is required if and only if the
 // compilation flow is impacted, e.g. due to a difference of syntax or
 // semantics in the language compared to the core standard.
 
-#ifndef OPENCLEXT_INTERNAL
+#ifndef OPENCLCOREEXT_INTERNAL
   #ifndef OPENCLEXT
-#pragma error "macro OPENCLEXT or OPENCLEXT_INTERNAL is required"
+    #pragma error "macro OPENCLEXT or OPENCLCOREEXT_INTERNAL is required"
   #else
+    #define OPENCLCOREEXT_INTERNAL(ext, ...) OPENCLEXT(ext)
     #define OPENCLEXT_INTERNAL(ext, ...) OPENCLEXT(ext)
   #endif // OPENCLEXT
-#endif // OPENCLEXT_INTERNAL
+#else  // OPENCLCOREEXT_INTERNAL
+  #define OPENCLEXT_INTERNAL(ext, avail) OPENCLCOREEXT_INTERNAL(ext, avail, ~0U)
+#endif // OPENCLCOREEXT_INTERNAL
+
+#ifndef OPENCLFEAT_INTERNAL
+  #ifndef OPENCLEXT
+    #pragma error "macro OPENCLEXT or OPENCLFEAT_INTERNAL is required"
+  #else
+    #define OPENCLFEAT_INTERNAL(feat,...) OPENCLEXT(feat)
+  #endif // OPENCLEXT
+#endif // OPENCLFEAT_INTERNAL
+
 
 // OpenCL 1.0.
-OPENCLEXT_INTERNAL(cl_khr_3d_image_writes, 100, 200)
-OPENCLEXT_INTERNAL(cl_khr_byte_addressable_store, 100, 110)
-OPENCLEXT_INTERNAL(cl_khr_fp16, 100, ~0U)
-OPENCLEXT_INTERNAL(cl_khr_fp64, 100, 120)
-OPENCLEXT_INTERNAL(cl_khr_global_int32_base_atomics, 100, 110)
-OPENCLEXT_INTERNAL(cl_khr_global_int32_extended_atomics, 100, 110)
-OPENCLEXT_INTERNAL(cl_khr_local_int32_base_atomics, 100, 110)
-OPENCLEXT_INTERNAL(cl_khr_local_int32_extended_atomics, 100, 110)
-OPENCLEXT_INTERNAL(cl_khr_int64_base_atomics, 100, ~0U)
-OPENCLEXT_INTERNAL(cl_khr_int64_extended_atomics, 100, ~0U)
+OPENCLEXT_INTERNAL(cl_khr_fp16, 100)
+OPENCLEXT_INTERNAL(cl_khr_int64_base_atomics, 100)
+OPENCLEXT_INTERNAL(cl_khr_int64_extended_atomics, 100)
+OPENCLCOREEXT_INTERNAL(cl_khr_3d_image_writes, 100, 200)
+OPENCLCOREEXT_INTERNAL(cl_khr_byte_addressable_store, 100, 110)
+OPENCLCOREEXT_INTERNAL(cl_khr_fp64, 100, 120)
+OPENCLCOREEXT_INTERNAL(cl_khr_global_int32_base_atomics, 100, 110)
+OPENCLCOREEXT_INTERNAL(cl_khr_global_int32_extended_atomics, 100, 110)
+OPENCLCOREEXT_INTERNAL(cl_khr_local_int32_base_atomics, 100, 110)
+OPENCLCOREEXT_INTERNAL(cl_khr_local_int32_extended_atomics, 100, 110)
 
 // EMBEDDED_PROFILE
-OPENCLEXT_INTERNAL(cles_khr_int64, 110, ~0U)
+OPENCLEXT_INTERNAL(cles_khr_int64, 110)
 
 // OpenCL 1.2.
-OPENCLEXT_INTERNAL(cl_khr_depth_images, 120, ~0U)
-OPENCLEXT_INTERNAL(cl_khr_gl_msaa_sharing, 120, ~0U)
+OPENCLEXT_INTERNAL(cl_khr_depth_images, 120)
+OPENCLEXT_INTERNAL(cl_khr_gl_msaa_sharing, 120)
 
 // OpenCL 2.0.
-OPENCLEXT_INTERNAL(cl_khr_mipmap_image, 200, ~0U)
-OPENCLEXT_INTERNAL(cl_khr_mipmap_image_writes, 200, ~0U)
-OPENCLEXT_INTERNAL(cl_khr_srgb_image_writes, 200, ~0U)
-OPENCLEXT_INTERNAL(cl_khr_subgroups, 200, ~0U)
-OPENCLEXT_INTERNAL(cl_khr_subgroup_extended_types, 200, ~0U)
-OPENCLEXT_INTERNAL(cl_khr_subgroup_non_uniform_vote, 200, ~0U)
-OPENCLEXT_INTERNAL(cl_khr_subgroup_ballot, 200, ~0U)
-OPENCLEXT_INTERNAL(cl_khr_subgroup_non_uniform_arithmetic, 200, ~0U)
-OPENCLEXT_INTERNAL(cl_khr_subgroup_shuffle, 200, ~0U)
-OPENCLEXT_INTERNAL(cl_khr_subgroup_shuffle_relative, 200, ~0U)
-OPENCLEXT_INTERNAL(cl_khr_subgroup_clustered_reduce, 200, ~0U)
+OPENCLEXT_INTERNAL(cl_khr_mipmap_image, 200)
+OPENCLEXT_INTERNAL(cl_khr_mipmap_image_writes, 200)
+OPENCLEXT_INTERNAL(cl_khr_srgb_image_writes, 200)
+OPENCLEXT_INTERNAL(cl_khr_subgroups, 200)
+OPENCLEXT_INTERNAL(cl_khr_subgroup_extended_types, 200)
+OPENCLEXT_INTERNAL(cl_khr_subgroup_non_uniform_vote, 200)
+OPENCLEXT_INTERNAL(cl_khr_subgroup_ballot, 200)
+OPENCLEXT_INTERNAL(cl_khr_subgroup_non_uniform_arithmetic, 200)
+OPENCLEXT_INTERNAL(cl_khr_subgroup_shuffle, 200)
+OPENCLEXT_INTERNAL(cl_khr_subgroup_shuffle_relative, 200)
+OPENCLEXT_INTERNAL(cl_khr_subgroup_clustered_reduce, 200)
 
 // Clang Extensions.
-OPENCLEXT_INTERNAL(cl_clang_storage_class_specifiers, 100, ~0U)
+OPENCLEXT_INTERNAL(cl_clang_storage_class_specifiers, 100)
 
 // AMD OpenCL extensions
-OPENCLEXT_INTERNAL(cl_amd_media_ops, 100, ~0U)
-OPENCLEXT_INTERNAL(cl_amd_media_ops2, 100, ~0U)
+OPENCLEXT_INTERNAL(cl_amd_media_ops, 100)
+OPENCLEXT_INTERNAL(cl_amd_media_ops2, 100)
 
 // ARM OpenCL extensions
-OPENCLEXT_INTERNAL(cl_arm_integer_dot_product_int8, 120, ~0U)
-OPENCLEXT_INTERNAL(cl_arm_integer_dot_product_accumulate_int8, 120, ~0U)
-OPENCLEXT_INTERNAL(cl_arm_integer_dot_product_accumulate_int16, 120, ~0U)
-OPENCLEXT_INTERNAL(cl_arm_integer_dot_product_accumulate_saturate_int8, 120, ~0U)
+OPENCLEXT_INTERNAL(cl_arm_integer_dot_product_int8, 120)
+OPENCLEXT_INTERNAL(cl_arm_integer_dot_product_accumulate_int8, 120)
+OPENCLEXT_INTERNAL(cl_arm_integer_dot_product_accumulate_int16, 120)
+OPENCLEXT_INTERNAL(cl_arm_integer_dot_product_accumulate_saturate_int8, 120)
 
 // Intel OpenCL extensions
-OPENCLEXT_INTERNAL(cl_intel_subgroups, 120, ~0U)
-OPENCLEXT_INTERNAL(cl_intel_subgroups_short, 120, ~0U)
-OPENCLEXT_INTERNAL(cl_intel_device_side_avc_motion_estimation, 120, ~0U)
+OPENCLEXT_INTERNAL(cl_intel_subgroups, 120)
+OPENCLEXT_INTERNAL(cl_intel_subgroups_short, 120)
+OPENCLEXT_INTERNAL(cl_intel_device_side_avc_motion_estimation, 120)
+
+// OpenCL C 3.0 features (6.2.1. Features)
+OPENCLFEAT_INTERNAL(__opencl_c_pipes, 200, "")
+OPENCLFEAT_INTERNAL(__opencl_c_generic_address_space, 200, "")
+OPENCLFEAT_INTERNAL(__opencl_c_atomic_order_acq_rel, 200, "")
+OPENCLFEAT_INTERNAL(__opencl_c_atomic_order_seq_cst, 200, "")
+OPENCLFEAT_INTERNAL(__opencl_c_device_enqueue, 200, "")
+OPENCLFEAT_INTERNAL(__opencl_c_read_write_images, 200, "")
+OPENCLFEAT_INTERNAL(__opencl_c_program_scope_global_variables, 200, "")
+OPENCLFEAT_INTERNAL(__opencl_c_fp64, 300, "cl_khr_fp64")
+OPENCLFEAT_INTERNAL(__opencl_c_images, 100, "")
+
+// OpenCL C 3.0 only. Earlier versions should use extensions
+// for following functionallity:
+OPENCLFEAT_INTERNAL(__opencl_c_3d_image_writes, 300, "cl_khr_3d_image_writes")
+OPENCLFEAT_INTERNAL(__opencl_c_fp64, 300, "cl_khr_fp64")
+
+// Note that __opencl_c_subgroups and cl_khr_subgroups are not equivalent
+// as extension requires sub-group independent forward progress (4.2. Querying Devices)
+OPENCLFEAT_INTERNAL(__opencl_c_subgroups, 300, "")
 
 #undef OPENCLEXT_INTERNAL
+#undef OPENCLCOREEXT_INTERNAL
+#undef OPENCLFEAT_INTERNAL
 
 #ifdef OPENCLEXT
 #undef OPENCLEXT
 #endif

clang/include/clang/Basic/OpenCLOptions.h

 #include "clang/Basic/LangOptions.h"
 #include "llvm/ADT/StringMap.h"
 
 namespace clang {
 
 /// OpenCL supported extensions and optional core features
 class OpenCLOptions {
   struct Info {
-    bool Supported; // Is this option supported
-    bool Enabled;   // Is this option enabled
-    unsigned Avail; // Option starts to be available in this OpenCL version
-    unsigned Core;  // Option becomes (optional) core feature in this OpenCL
-                    // version
-    Info(bool S = false, bool E = false, unsigned A = 100, unsigned C = ~0U)
-      :Supported(S), Enabled(E), Avail(A), Core(C){}
+    bool Supported = false; // Is this option supported
+    bool Enabled = false;   // Is this option enabled
+    bool IsFeature = false; // Is this OpenCL feature
+    unsigned Avail =
+        100;             // Option starts to be available in this OpenCL version
+    unsigned Core = ~0U; // Option becomes (optional) core feature in this
+                         // OpenCL version
   };
+
+  // OpenCL Version
+  unsigned CLVer = 120;
+
   llvm::StringMap<Info> OptMap;
+
+  // e.g. __opencl_c_fp64 and cl_khr_fp64
+  llvm::StringMap<StringRef> EquivalentFeaturesExtensions;
+
+  // For pre-OpenCL C 3.0 features are supported unconditionally
+  bool isSupportedFeatureForPreOCL30(llvm::StringRef Feat) const {
+    assert(CLVer < 300 && "Can't be called for OpenCL C 3.0 or higher");
+    auto I = OptMap.find(Feat)->getValue();
+    return I.IsFeature && I.Avail <= CLVer;
+  }
+
+  void supportFeaturesForPreOCL30() {
+    assert(CLVer < 300 && "Can't be called for OpenCL C 3.0 or higher");
+    for (auto &Opt : OptMap)
+      if (isSupportedFeatureForPreOCL30(Opt.getKey()))
+        OptMap[Opt.getKey()].Supported = true;
+  }
+
+  // Simultaneously support feature and equivalent extension.
+  void supportSameExtensionsForSupportedFeatures() {
+    assert(CLVer >= 300 && "Can be called only for OpenCL C 3.0 or higher");
+    for (auto &FeatExt : EquivalentFeaturesExtensions)
+      OptMap[FeatExt.getValue()].Supported = OptMap[FeatExt.getKey()].Supported;
+  }
+
 public:
+  void setOpenCLVersion(const LangOptions &LO) {
+    // In C++ mode all extensions should work at least as in v2.0.
+    CLVer = LO.OpenCLCPlusPlus ? 200 : LO.OpenCLVersion;
+  }
+
   bool isKnown(llvm::StringRef Ext) const {
     return OptMap.find(Ext) != OptMap.end();
   }
 
   bool isEnabled(llvm::StringRef Ext) const {
     return OptMap.find(Ext)->second.Enabled;
   }
 
   // Is supported as either an extension or an (optional) core feature for
   // OpenCL version \p CLVer.
-  bool isSupported(llvm::StringRef Ext, const LangOptions &LO) const {
-    // In C++ mode all extensions should work at least as in v2.0.
-    auto CLVer = LO.OpenCLCPlusPlus ? 200 : LO.OpenCLVersion;
+  bool isSupported(llvm::StringRef Ext) const {
     auto I = OptMap.find(Ext)->getValue();
     return I.Supported && I.Avail <= CLVer;
   }
 
   // Is supported (optional) OpenCL core features for OpenCL version \p CLVer.
   // For supported extension, return false.
-  bool isSupportedCore(llvm::StringRef Ext, const LangOptions &LO) const {
-    // In C++ mode all extensions should work at least as in v2.0.
-    auto CLVer = LO.OpenCLCPlusPlus ? 200 : LO.OpenCLVersion;
+  bool isSupportedCore(llvm::StringRef Ext) const {
     auto I = OptMap.find(Ext)->getValue();
     return I.Supported && I.Avail <= CLVer && I.Core != ~0U && CLVer >= I.Core;
   }
 
   // Is supported OpenCL extension for OpenCL version \p CLVer.
   // For supported (optional) core feature, return false.
-  bool isSupportedExtension(llvm::StringRef Ext, const LangOptions &LO) const {
-    // In C++ mode all extensions should work at least as in v2.0.
-    auto CLVer = LO.OpenCLCPlusPlus ? 200 : LO.OpenCLVersion;
+  bool isSupportedExtension(llvm::StringRef Ext) const {
     auto I = OptMap.find(Ext)->getValue();
     return I.Supported && I.Avail <= CLVer && (I.Core == ~0U || CLVer < I.Core);
   }
 
   void enable(llvm::StringRef Ext, bool V = true) {
     OptMap[Ext].Enabled = V;
   }
 
   /// Enable or disable support for OpenCL extensions
   /// \param Ext name of the extension optionally prefixed with
   ///        '+' or '-'
   /// \param V used when \p Ext is not prefixed by '+' or '-'
   void support(llvm::StringRef Ext, bool V = true) {
     assert(!Ext.empty() && "Extension is empty.");
-
     switch (Ext[0]) {
     case '+':
       V = true;
       Ext = Ext.drop_front();
       break;
     case '-':
       V = false;
       Ext = Ext.drop_front();
       break;
     }
 
     if (Ext.equals("all")) {
       supportAll(V);
       return;
     }
-    OptMap[Ext].Supported = V;
+
+    auto &Info = OptMap[Ext];
+
+    if (Info.IsFeature && (CLVer < 300) && V) {
+      if (isSupportedFeatureForPreOCL30(Ext))
+        Info.Supported = true;
+    } else
+      Info.Supported = V;
+  }
+
+  void addSupport(const OpenCLOptions &Opts) {
+    for (auto &I : Opts.OptMap)
+      if (I.second.Supported)
+        support(I.getKey(), true);
   }
 
   OpenCLOptions(){
-#define OPENCLEXT_INTERNAL(Ext, AvailVer, CoreVer) \
-    OptMap[#Ext].Avail = AvailVer; \
-    OptMap[#Ext].Core = CoreVer;
+#define OPENCLCOREEXT_INTERNAL(Ext, AvailVer, CoreVer)                         \
+  OptMap[#Ext].Avail = AvailVer;                                               \
+#define OPENCLFEAT_INTERNAL(Feat, AvailVer, SameExt)                           \
+  OptMap[#Feat].Avail = AvailVer;                                              \
+  OptMap[#Feat].IsFeature = true;                                              \
+  if (llvm::StringRef(SameExt) != "")                                          \
+    EquivalentFeaturesExtensions[#Feat] = SameExt;
 #include "clang/Basic/OpenCLExtensions.def"
   }
 
-  void addSupport(const OpenCLOptions &Opts) {
-    for (auto &I:Opts.OptMap)
-      if (I.second.Supported)
-        OptMap[I.getKey()].Supported = true;
+  // Adjust existing OpenCL feature and extension support
+  void adjustFeatures() {
+    if (CLVer >= 300) {
+      supportSameExtensionsForSupportedFeatures();
+      // OpenCL C compilers that define the feature macro __opencl_c_pipes or
+      // or __opencl_c_device_enqueue must also define the
+      // feature macro __opencl_c_generic_address_space.
+      if (OptMap["__opencl_c_pipes"].Supported ||
+          OptMap["__opencl_c_device_enqueue"].Supported)
+        OptMap["__opencl_c_generic_address_space"].Supported = true;
+      // For OpenCL C 3.0 all other features are to be set by the
+      // targets or option explicitly.
+      return;
+    }
+    supportFeaturesForPreOCL30();
   }
 
   void copy(const OpenCLOptions &Opts) {
+    CLVer = Opts.CLVer;
     OptMap = Opts.OptMap;
+    EquivalentFeaturesExtensions = Opts.EquivalentFeaturesExtensions;
   }
 
   // Turn on or off support of all options.
   void supportAll(bool On = true) {
     for (llvm::StringMap<Info>::iterator I = OptMap.begin(),
          E = OptMap.end(); I != E; ++I)
-      I->second.Supported = On;
+      support(I->getKey(), On);
   }
 
-  void disableAll() {
+  void disableAllExtensions() {
     for (llvm::StringMap<Info>::iterator I = OptMap.begin(),
          E = OptMap.end(); I != E; ++I)
       I->second.Enabled = false;
   }
 
-  void enableSupportedCore(LangOptions LO) {
+  void enableSupportedCore() {
     for (llvm::StringMap<Info>::iterator I = OptMap.begin(), E = OptMap.end();
          I != E; ++I)
-      if (isSupportedCore(I->getKey(), LO))
+      if (isSupportedCore(I->getKey()))
         I->second.Enabled = true;
   }
 
   friend class ASTWriter;
   friend class ASTReader;
 };
 
 } // end namespace clang
 
 #endif

clang/include/clang/Basic/TargetInfo.h

   checkCFProtectionReturnSupported(DiagnosticsEngine &Diags) const;
 
   /// Whether target allows to overalign ABI-specified preferred alignment
   virtual bool allowsLargerPreferedTypeAlignment() const { return true; }
 
   /// Whether target defaults to the `power` alignment rules of AIX.
   virtual bool defaultsToAIXPowerAlignment() const { return false; }
 
-  /// Set supported OpenCL extensions and optional core features.
-  virtual void setSupportedOpenCLOpts() {}
-
-  /// Set supported OpenCL extensions as written on command line
-  virtual void setOpenCLExtensionOpts() {
-    for (const auto &Ext : getTargetOpts().OpenCLExtensionsAsWritten) {
-      getTargetOpts().SupportedOpenCLOptions.support(Ext);
-    }
+  /// Set OpenCL features/extensions supported by target settings and option
+  void setOpenCLExtensions(const LangOptions &Opts) {
+    getTargetOpts().SupportedOpenCLOptions.setOpenCLVersion(Opts);
+    // Set options supported by the target
+    setSupportedOpenCLOpts();
+    // Set option provided in option
+    setOpenCLExtensionOpts();
+    // Adjust supported options
+    getTargetOpts().SupportedOpenCLOptions.adjustFeatures();
   }
 
   /// Get supported OpenCL extensions and optional core features.
   OpenCLOptions &getSupportedOpenCLOpts() {
     return getTargetOpts().SupportedOpenCLOptions;
   }
 
   /// Get const supported OpenCL extensions and optional core features.

   }
 
   virtual void setAuxTarget(const TargetInfo *Aux) {}
 
   /// Whether target allows debuginfo types for decl only variables.
   virtual bool allowDebugInfoForExternalVar() const { return false; }
 
 protected:
+  /// Set supported OpenCL extensions and optional core features.
+  virtual void setSupportedOpenCLOpts() {}
+  /// Set supported OpenCL extensions as written on command line
+  virtual void setOpenCLExtensionOpts() {
+    for (const auto &Ext : getTargetOpts().OpenCLExtensionsAsWritten) {
+      getTargetOpts().SupportedOpenCLOptions.support(Ext);
+    }
+  }
   /// Copy type and layout related info.
   void copyAuxTarget(const TargetInfo *Aux);
   virtual uint64_t getPointerWidthV(unsigned AddrSpace) const {
     return PointerWidth;
   }
   virtual uint64_t getPointerAlignV(unsigned AddrSpace) const {
     return PointerAlign;
   }

clang/lib/Basic/TargetInfo.cpp

void TargetInfo::adjust(LangOptions &Opts) {
   }
 
   if (Opts.AlignDouble) {
     DoubleAlign = LongLongAlign = 64;
     LongDoubleAlign = 64;
   }
 
   if (Opts.OpenCL) {
+    setOpenCLExtensions(Opts);
+
     // OpenCL C requires specific widths for types, irrespective of
     // what these normally are for the target.
     // We also define long long and long double here, although the
     // OpenCL standard only mentions these as "reserved".
     IntWidth = IntAlign = 32;
     LongWidth = LongAlign = 64;
     LongLongWidth = LongLongAlign = 128;
     HalfWidth = HalfAlign = 16;

clang/lib/Basic/Targets.cpp

for (const auto &F : Opts->FeatureMap)
     Opts->Features.push_back((F.getValue() ? "+" : "-") + F.getKey().str());
   // Sort here, so we handle the features in a predictable order. (This matters
   // when we're dealing with features that overlap.)
   llvm::sort(Opts->Features);
 
   if (!Target->handleTargetFeatures(Opts->Features, Diags))
     return nullptr;
 
-  Target->setSupportedOpenCLOpts();
-  Target->setOpenCLExtensionOpts();
   Target->setMaxAtomicWidth();
 
   if (!Target->validateTarget(Diags))
     return nullptr;
 
   Target->CheckFixedPointBits();
 
   return Target.release();
 }

clang/lib/Frontend/InitPreprocessor.cpp

#undef DEFINE_LOCK_FREE_MACRO
   // SYCL device compiler which doesn't produce host binary.
   if (LangOpts.SYCLIsDevice) {
     Builder.defineMacro("__SYCL_DEVICE_ONLY__", "1");
   }
 
   // OpenCL definitions.
   if (LangOpts.OpenCL) {
 #define OPENCLEXT(Ext)                                                         \
-  if (TI.getSupportedOpenCLOpts().isSupported(#Ext, LangOpts))                 \
+  if (TI.getSupportedOpenCLOpts().isSupported(#Ext))                           \
     Builder.defineMacro(#Ext);
 #include "clang/Basic/OpenCLExtensions.def"
 
     if (TI.getTriple().isSPIR())
       Builder.defineMacro("__IMAGE_SUPPORT__");
+
+    // Assume compiling for FULL profile
+    Builder.defineMacro("__opencl_c_int64");
   }
 
   if (TI.hasInt128Type() && LangOpts.CPlusPlus && LangOpts.GNUMode) {
     // For each extended integer type, g++ defines a macro mapping the
     // index of the type (0 in this case) in some list of extended types
     // to the type.
     Builder.defineMacro("__GLIBCXX_TYPE_INT_N_0", "__int128");
     Builder.defineMacro("__GLIBCXX_BITSIZE_INT_N_0", "128");

clang/lib/Headers/opencl-c-base.h

 //===----- opencl-c-base.h - OpenCL C language base definitions -----------===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
 // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 //===----------------------------------------------------------------------===//
 
 #ifndef _OPENCL_BASE_H_
 #define _OPENCL_BASE_H_
 
+// Define OpenCL header-only features for pre-OpenCL C 3.0
+#if defined(__OPENCL_CPP_VERSION__) || (__OPENCL_C_VERSION__ == CL_VERSION_2_0)
+#define __opencl_c_atomic_scope_device 1
+#define __opencl_c_atomic_scope_all_devices 1
+#define __opencl_c_work_group_collective_functions 1
+#endif
+
 // built-in scalar data types:
 
 /**
  * An unsigned 8-bit integer.
  */
 typedef unsigned char uchar;
 
 /**

clang/lib/Parse/ParsePragma.cpp

void Parser::HandlePragmaOpenCLExtension() {
 
   auto &Opt = Actions.getOpenCLOptions();
   auto Name = Ident->getName();
   // OpenCL 1.1 9.1: "The all variant sets the behavior for all extensions,
   // overriding all previously issued extension directives, but only if the
   // behavior is set to disable."
   if (Name == "all") {
     if (State == Disable) {
-      Opt.disableAll();
-      Opt.enableSupportedCore(getLangOpts());
+      Opt.disableAllExtensions();
+      Opt.enableSupportedCore();
     } else {
       PP.Diag(NameLoc, diag::warn_pragma_expected_predicate) << 1;
     }
   } else if (State == Begin) {
-    if (!Opt.isKnown(Name) || !Opt.isSupported(Name, getLangOpts())) {
+    if (!Opt.isKnown(Name) || !Opt.isSupported(Name)) {
       Opt.support(Name);
     }
     Actions.setCurrentOpenCLExtension(Name);
   } else if (State == End) {
     if (Name != Actions.getCurrentOpenCLExtension())
       PP.Diag(NameLoc, diag::warn_pragma_begin_end_mismatch);
     Actions.setCurrentOpenCLExtension("");
   } else if (!Opt.isKnown(Name))
     PP.Diag(NameLoc, diag::warn_pragma_unknown_extension) << Ident;
-  else if (Opt.isSupportedExtension(Name, getLangOpts()))
+  else if (Opt.isSupportedExtension(Name))
     Opt.enable(Name, State == Enable);
-  else if (Opt.isSupportedCore(Name, getLangOpts()))
+  else if (Opt.isSupportedCore(Name))
     PP.Diag(NameLoc, diag::warn_pragma_extension_is_core) << Ident;
   else
     PP.Diag(NameLoc, diag::warn_pragma_unsupported_extension) << Ident;
 }
 
 void Parser::HandlePragmaMSPointersToMembers() {
   assert(Tok.is(tok::annot_pragma_ms_pointers_to_members));
   LangOptions::PragmaMSPointersToMembersKind RepresentationMethod =

clang/lib/Sema/Sema.cpp

if (getLangOpts().CPlusPlus &&
                         TUScope);
 
     addImplicitTypedef("size_t", Context.getSizeType());
   }
 
   // Initialize predefined OpenCL types and supported extensions and (optional)
   // core features.
   if (getLangOpts().OpenCL) {
+    getOpenCLOptions().setOpenCLVersion(getLangOpts());
     getOpenCLOptions().addSupport(
         Context.getTargetInfo().getSupportedOpenCLOpts());
-    getOpenCLOptions().enableSupportedCore(getLangOpts());
+    getOpenCLOptions().enableSupportedCore();
     addImplicitTypedef("sampler_t", Context.OCLSamplerTy);
     addImplicitTypedef("event_t", Context.OCLEventTy);
     if (getLangOpts().OpenCLCPlusPlus || getLangOpts().OpenCLVersion >= 200) {
       addImplicitTypedef("clk_event_t", Context.OCLClkEventTy);
       addImplicitTypedef("queue_t", Context.OCLQueueTy);
       addImplicitTypedef("reserve_id_t", Context.OCLReserveIDTy);
       addImplicitTypedef("atomic_int", Context.getAtomicType(Context.IntTy));
       addImplicitTypedef("atomic_uint",

clang/lib/Serialization/ASTReader.cpp

case FP_PRAGMA_OPTIONS:
       break;
 
     case OPENCL_EXTENSIONS:
       for (unsigned I = 0, E = Record.size(); I != E; ) {
         auto Name = ReadString(Record, I);
         auto &Opt = OpenCLExtensions.OptMap[Name];
         Opt.Supported = Record[I++] != 0;
         Opt.Enabled = Record[I++] != 0;
+        Opt.IsFeature = Record[I++] != 0;
         Opt.Avail = Record[I++];
         Opt.Core = Record[I++];
       }
       break;
 
     case OPENCL_EXTENSION_TYPES:
       for (unsigned I = 0, E = Record.size(); I != E;) {
         auto TypeID = static_cast<::TypeID>(Record[I++]);

clang/lib/Serialization/ASTWriter.cpp

void ASTWriter::WriteOpenCLExtensions(Sema &SemaRef) {
 
   const OpenCLOptions &Opts = SemaRef.getOpenCLOptions();
   RecordData Record;
   for (const auto &I:Opts.OptMap) {
     AddString(I.getKey(), Record);
     auto V = I.getValue();
     Record.push_back(V.Supported ? 1 : 0);
     Record.push_back(V.Enabled ? 1 : 0);
+    Record.push_back(V.IsFeature ? 1 : 0);
     Record.push_back(V.Avail);
     Record.push_back(V.Core);
   }
   Stream.EmitRecord(OPENCL_EXTENSIONS, Record);
 }
 
 void ASTWriter::WriteOpenCLExtensionTypes(Sema &SemaRef) {
   if (!SemaRef.Context.getLangOpts().OpenCL)

clang/test/SemaOpenCL/opencl-feature-extension-simult.cl

+// Testing with target which doesn't support 3d image writes and fp64
+
+// RUN: %clang_cc1 %s -triple r600-unknown-unknown -E -cl-std=CL3.0 -cl-ext=-all,__opencl_c_fp64
+// RUN: %clang_cc1 %s -triple r600-unknown-unknown -E -cl-std=CL3.0 -cl-ext=+__opencl_c_fp64
+// RUN: %clang_cc1 %s -triple r600-unknown-unknown -E -cl-std=CL3.0 -cl-ext=+__opencl_c_3d_image_writes
+// RUN: %clang_cc1 %s -triple r600-unknown-unknown -E -cl-std=CL3.0 -cl-ext=+__opencl_c_pipes
+// RUN: %clang_cc1 %s -triple r600-unknown-unknown -E -cl-std=CL3.0 -cl-ext=+__opencl_c_device_enqueue
+// RUN: %clang_cc1 %s -triple r600-unknown-unknown -E -cl-std=CL3.0 -cl-ext=+__opencl_c_read_write_images
+// RUN: %clang_cc1 %s -triple r600-unknown-unknown -E -cl-std=CL3.0 -cl-ext=+__opencl_c_fp64,-cl_khr_fp64
+// RUN: %clang_cc1 %s -triple r600-unknown-unknown -E -cl-std=CL3.0 -cl-ext=+__opencl_c_3d_image_writes,-cl_khr_3d_image_writes
+
+// expected-no-diagnostics
+
+#if (defined(cl_khr_fp64) && !defined(__opencl_c_fp64)) || \
+    (defined(__opencl_c_fp64) && !defined(cl_khr_fp64))
+  #error macros were not properly set up
+#endif
+
+#if (defined(cl_khr_3d_image_writes) && \
+     !defined(__opencl_c_3d_image_writes)) || \
+    (defined(__opencl_c_3d_image_writes) && !defined(cl_khr_3d_image_writes))
+  #error macros were not properly set up
+#endif

clang/test/SemaOpenCL/opencl-feature-generic-as-req.cl

+// RUN: %clang_cc1 %s -triple r600-unknown-unknown -E -cl-std=CL3.0 -cl-ext=+__opencl_c_pipes -DCHECK_PIPES
+// RUN: %clang_cc1 %s -triple r600-unknown-unknown -E -cl-std=CL3.0 -cl-ext=+__opencl_c_device_enqueue -DCHECK_ENQUEU
+// RUN: %clang_cc1 %s -triple spir64 -E -cl-std=CL3.0 -cl-ext=-all,+__opencl_c_pipes,-__opencl_c_generic_address_space -DCHECK_PIPES
+// RUN: %clang_cc1 %s -triple spir64 -E -cl-std=CL3.0 -cl-ext=-all,+__opencl_c_device_enqueue,-__opencl_c_generic_address_space -DCHECK_ENQUEUE
+
+// expected-no-diagnostics
+
+#ifdef CHECK_PIPES
+ #if !defined(__opencl_c_pipes)
+   #error macros were not properly set
+ #endif
+#endif
+
+#ifdef CHECK_ENQUEUE
+ #if !defined(__opencl_c_device_enqueue)
+   #error macros were not properly set
+ #endif
+#endif
+
+#if defined(__opencl_c_pipes) || defined(__opencl_c_device_enqueue) 
+  #if !defined(__opencl_c_generic_address_space)
+    #error macros were not properly set
+  #endif
+#endif

clang/test/SemaOpenCL/opencl-features.cl

+// RUN: %clang_cc1 -triple amdgcn-unknown-unknown -finclude-default-header %s -E -dM -o - -x cl -cl-std=CL2.0 \
+// RUN:   | FileCheck -match-full-lines %s --check-prefix=CL20
+// RUN: %clang_cc1 -triple amdgcn-unknown-unknown -finclude-default-header %s -E -dM -o - -x cl -cl-std=CL2.0 -cl-ext=-all \
+// RUN:   | FileCheck -match-full-lines %s  --check-prefix=CL20
+// RUN: %clang_cc1 -triple amdgcn-unknown-unknown -finclude-default-header %s -E -dM -o - -x cl -cl-std=CLC++ \
+// RUN:   | FileCheck -match-full-lines %s  --check-prefix=CL20
+// RUN: %clang_cc1 -triple r600-unknown-unknown -finclude-default-header %s -E -dM -o - -x cl -cl-std=CL2.0 \
+// RUN:   | FileCheck -match-full-lines %s  --check-prefix=CL20
+// RUN: %clang_cc1 -triple r600-unknown-unknown -finclude-default-header %s -E -dM -o - -x cl -cl-std=CL2.0 -cl-ext=-all \
+// RUN:   | FileCheck -match-full-lines %s  --check-prefix=CL20
+// RUN: %clang_cc1 -triple r600-unknown-unknown -finclude-default-header %s -E -dM -o - -x cl -cl-std=CLC++ \
+// RUN:   | FileCheck -match-full-lines %s  --check-prefix=CL20
+// RUN: %clang_cc1 -triple nvptx-unknown-unknown -finclude-default-header %s -E -dM -o - -x cl -cl-std=CL2.0 \
+// RUN:   | FileCheck -match-full-lines %s  --check-prefix=CL20
+// RUN: %clang_cc1 -triple nvptx-unknown-unknown -finclude-default-header %s -E -dM -o - -x cl -cl-std=CL2.0 -cl-ext=-all \
+// RUN:   | FileCheck -match-full-lines %s  --check-prefix=CL20
+// RUN: %clang_cc1 -triple nvptx-unknown-unknown -finclude-default-header %s -E -dM -o - -x cl -cl-std=CLC++ \
+// RUN:   | FileCheck -match-full-lines %s  --check-prefix=CL20
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -finclude-default-header %s -E -dM -o - -x cl -cl-std=CL2.0 \
+// RUN:   | FileCheck -match-full-lines %s  --check-prefix=CL20
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -finclude-default-header %s -E -dM -o - -x cl -cl-std=CL2.0  -cl-ext=-all \
+// RUN:   | FileCheck -match-full-lines %s  --check-prefix=CL20
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -finclude-default-header %s -E -dM -o - -x cl -cl-std=CLC++ \
+// RUN:   | FileCheck -match-full-lines %s  --check-prefix=CL20
+// RUN: %clang_cc1 -triple spir-unknown-unknown -finclude-default-header %s -E -dM -o - -x cl -cl-std=CL2.0 \
+// RUN:   | FileCheck -match-full-lines %s  --check-prefix=CL20
+// RUN: %clang_cc1 -triple r600-unknown-unknown -finclude-default-header %s -E -dM -o - -x cl -cl-std=CL2.0 -cl-ext=-all \
+// RUN:   | FileCheck -match-full-lines %s  --check-prefix=CL20
+// RUN: %clang_cc1 -triple spir-unknown-unknown -finclude-default-header %s -E -dM -o - -x cl -cl-std=CLC++ \
+// RUN:   | FileCheck -match-full-lines %s  --check-prefix=CL20
+
+// x86_64 and spir support all features by default
+
+// RUN: %clang_cc1 -triple amdgcn-unknown-unknown -finclude-default-header %s -E -dM -o - -x cl -cl-std=CL3.0 \
+// RUN:   | FileCheck -match-full-lines %s  --check-prefix=CL30
+// RUN: %clang_cc1 -triple r600-unknown-unknown -finclude-default-header %s -E -dM -o - -x cl -cl-std=CL3.0 \
+// RUN:   | FileCheck -match-full-lines %s  --check-prefix=CL30
+// RUN: %clang_cc1 -triple nvptx-unknown-unknown -finclude-default-header %s -E -dM -o - -x cl -cl-std=CL3.0 \
+// RUN:   | FileCheck -match-full-lines %s  --check-prefix=CL30
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -finclude-default-header %s -E -dM -o - -x cl -cl-std=CL3.0 -cl-ext=-all \
+// RUN:   | FileCheck -match-full-lines %s  --check-prefix=CL30
+// RUN: %clang_cc1 -triple spir-unknown-unknown -finclude-default-header %s -E -dM -o - -x cl -cl-std=CL3.0 -cl-ext=-all \
+// RUN:   | FileCheck -match-full-lines %s  --check-prefix=CL30
+
+// CL20: #define __opencl_c_atomic_order_acq_rel 1
+// CL20: #define __opencl_c_atomic_order_seq_cst 1
+// CL20: #define __opencl_c_atomic_scope_all_devices 1
+// CL20: #define __opencl_c_atomic_scope_device 1
+// CL20: #define __opencl_c_device_enqueue 1
+// CL20: #define __opencl_c_generic_address_space 1
+// CL20: #define __opencl_c_images 1
+// CL20: #define __opencl_c_int64 1
+// CL20: #define __opencl_c_pipes 1
+// CL20: #define __opencl_c_program_scope_global_variables 1
+// CL20: #define __opencl_c_read_write_images 1
+// CL20: #define __opencl_c_work_group_collective_functions 1
+// CL20-NOT: __opencl_c_fp64
+// CL20-NOT: __opencl_c_3d_image_writes
+// CL20-NOT: __opencl_c_subgroups
+
+// CL30: #define __opencl_c_int64 1
+// CL30-NOT: __opencl_c_atomic_order_acq_rel
+// CL30-NOT: __opencl_c_atomic_order_seq_cst
+// CL30-NOT: __opencl_c_atomic_scope_all_devices
+// CL30-NOT: __opencl_c_atomic_scope_device
+// CL30-NOT: __opencl_c_device_enqueue
+// CL30-NOT: __opencl_c_generic_address_space
+// CL30-NOT: __opencl_c_images
+// CL30-NOT: __opencl_c_pipes
+// CL30-NOT: __opencl_c_program_scope_global_variables
+// CL30-NOT: __opencl_c_read_write_images
+// CL30-NOT: __opencl_c_work_group_collective_functions
+// CL30-NOT: __opencl_c_fp64
+// CL30-NOT: __opencl_c_3d_image_writes
+// CL30-NOT: __opencl_c_subgroups