[PATCH] D79781: [OpenCL] Add cl_khr_extended_subgroup extensions

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia accepted this revision.
Anastasia added a comment.

In D79781#2063440 <https://reviews.llvm.org/D79781#2063440>, @PiotrFusik wrote:

> Bumped the OpenCL version from 1.2 to 2.0.


Great! Thanks! Feel free to go ahead and commit this!

Can you please add a link to the bug describing incorrect optimization to this review once you create it.



================
Comment at: clang/include/clang/Basic/OpenCLExtensions.def:68
 OPENCLEXT_INTERNAL(cl_khr_spir, 120, ~0U)
+OPENCLEXT_INTERNAL(cl_khr_subgroup_extended_types, 120, ~0U)
+OPENCLEXT_INTERNAL(cl_khr_subgroup_non_uniform_vote, 120, ~0U)
----------------
PiotrFusik wrote:
> Anastasia wrote:
> > I think it makes sense to allow this extension from the same OpenCL version as normal subgroup. However the version listed somewhere in the spec?
> The spec doesn't mention the OpenCL version. Quoting the editor (Ben Ashbaugh):
> > My view of OpenCL extensions is that they are "non-versioned" – some extensions certainly make more sense for specific OpenCL versions, but if an older OpenCL implementation wants to support a newer extension (perhaps with some caveats or restrictions), or if a newer OpenCL version wants to support an older OpenCL extension for backwards compatibility, that should be possible.
> I agree that matching the version of `cl_khr_subgroups` makes sense. Updated together with the tests.
> 
I would say in upstream Clang we try to follow the commonly accepted and well-documented behavior. We have no capacity to work out what the behavior of every possible customization should be.

Also, we aim to implement already documented behavior that provides sufficient details to understand how things should be implemented. We can some times decide to deviate the implementation from the existing published documentation for which we should have a good reason and we should document anything that deviates any existing publicly documented feature.

Ideally OpenCL standard should decide whether extensions are associated with OpenCL versions or not and this should be clearly documented. It would certainly help the implementation as it saves us time to work out what language version should be taken as a base.

I believe that enabling extensions with incompatible language versions can cause the compiler failures without providing helpful information/diagnostic. Therefore, extensions should be aligned with a certain version of OpenCL C because they might require certain language features to be used. If they only require basic OpenCL language features then I guess it can say the extension is used with any language version starting from 1.0.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D79781/new/

https://reviews.llvm.org/D79781