[PATCH] D92231: [OpenCL] Implement extended subgroups fully in headers

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia added inline comments.


================
Comment at: clang/lib/Headers/opencl-c-base.h:17-23
+#define cl_khr_subgroup_extended_types
+#define cl_khr_subgroup_non_uniform_vote
+#define cl_khr_subgroup_ballot
+#define cl_khr_subgroup_non_uniform_arithmetic
+#define cl_khr_subgroup_shuffle
+#define cl_khr_subgroup_shuffle_relative
+#define cl_khr_subgroup_clustered_reduce
----------------
PiotrFusik wrote:
> Anastasia wrote:
> > PiotrFusik wrote:
> > > These are currently defined as "1": https://godbolt.org/z/MnoWeo
> > > Is the change to blank intentional?
> > > This should be tested.
> > Thanks! I think the spec doesn't specify the values but only says that the macros are defined
> > 
> > > Every extension which affects the OpenCL language semantics, syntax or adds built-in functions tothe  language  must  create  a  preprocessor  #define  that  matches  the  extension  name  string.  This #define  would  be  available  in  the  language  if  and  only  if  the  extension  is  supported  on  a  givenimplementation.
> > 
> > However, I think it makes sense to set the value `1` to align with the other extensions that are added by clang.
> > I think the spec doesn't specify the values but only says that the macros are defined
> 
> Yes, confirmed with Ben:
> 
> > I don’t think we’ve said anything about the extension #defines, but for the OpenCL C 3.0 feature test macros we required that they are defined to a value for precisely this reason (#if used instead of #ifdef):
> 
> > > In OpenCL C 3.0 or newer, feature macros must expand to the value 1 if the feature macro is defined by the OpenCL C compiler. A feature macro must not be defined if the feature is not supported by the OpenCL C compiler. A feature macro may expand to a different value in the future, but if this occurs the value of the feature macro must compare greater than the prior value of the feature macro.
> 
FYI, OpenCL 3.0 only determines the values for the feature macro but not the extension macro. Perhaps it's worth doing this for both?


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

https://reviews.llvm.org/D92231