Page MenuHomePhabricator

[OpenCL] Define OpenCL feature macros for all versions
AbandonedPublic

Authored by azabaznov on Oct 21 2020, 4:00 AM.

Details

Reviewers
Anastasia
svenvh
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.

Diff Detail

Event Timeline

azabaznov created this revision.Oct 21 2020, 4:00 AM
azabaznov requested review of this revision.Oct 21 2020, 4:00 AM

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

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.

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.

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 added inline comments.Nov 6 2020, 8:55 AM
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 updated this revision to Diff 304493.Nov 11 2020, 5:45 AM

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.

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.

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 added a comment.EditedNov 16 2020, 6:30 AM

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 added inline comments.Nov 17 2020, 2:39 AM
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 added inline comments.Nov 17 2020, 5:34 AM
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 added inline comments.Nov 18 2020, 6:58 AM
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 added inline comments.Nov 19 2020, 5:17 AM
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 updated this revision to Diff 307436.EditedNov 24 2020, 12:37 PM
azabaznov marked 24 inline comments as done.

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.

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 added inline comments.Nov 27 2020, 3:30 AM
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.

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 abandoned this revision.Feb 1 2021, 1:43 AM

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.