[PATCH] D95776: [OpenCL] Add macro definitions of OpenCL C 3.0 features

[Anton Zabaznov via Phabricator via cfe-commits]

azabaznov added inline comments.


================
Comment at: clang/lib/Basic/Targets.cpp:743
+  // Assume compiling for FULL profile
+  Builder.defineMacro("__opencl_c_int64");
 }
----------------
Anastasia wrote:
> Btw we could add the other feature macros for earlier versions too but I guess it makes code more complicated?
Yes, this will complicate things: we decided to generate a warning if any of core features is unsupported, right? So making OpenCL C 3.0 features as core in OpenCL C 2.0 will result in this kind of warning; distinguishing these features among the set of core functionality may require workarounds in clang, so let's keep them in headers only for OpenCL C 2.0.


================
Comment at: clang/lib/Headers/opencl-c.h:17161
+#if (defined(__OPENCL_CPP_VERSION__) || __OPENCL_C_VERSION__ == 200)
+#undef __opencl_c_pipes
+#undef __opencl_c_generic_address_space
----------------
svenvh wrote:
> Anastasia wrote:
> > Looping in @svenvh  - I don't mind if we define those macros in headers for OpenCL 2.0. The only concern is that if we `undef` them here we will end up with different behavior between `-finclude-default-header` and `-fdeclare-opencl-builtins`. I would suggest not to `undef` them because it is better if we have coherency. Alternatively we could also add a third header with undefs that can be included at the end for both but it seems to make things even more complicated.
> > 
> > FYI `__opencl_c_int64` is already added for all OpenCL versions.
> > The only concern is that if we undef them here we will end up with different behavior between -finclude-default-header and -fdeclare-opencl-builtins
> 
> This is a valid point.  Doing the undefs only in `opencl-c.h` will lead to a problem similar to https://reviews.llvm.org/D91429 .
> 
> A third header just for the undefs sounds like a bit of an overkill indeed, although having duplication isn't great either.  Not sure what's best to be honest.
My idea was just to temporary define features for built-ins and enums definitions as this is the only place where these macros may be useful for OpenCL C 2.0. However, I don't have any strong concerns if these macros will remain defined.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95776