svenvh added a comment. In D107769#2967565 <https://reviews.llvm.org/D107769#2967565>, @Anastasia wrote:
> In D107769#2960441 <https://reviews.llvm.org/D107769#2960441>, @svenvh wrote: > >> I have done an alternative spin of this patch: instead of introducing >> `RequireDisabledExtension`, simply always make the `private`, `global`, and >> `local` overloads available. This makes tablegen diverge from `opencl-c.h` >> though. Perhaps we should also always add make the `private`, `global`, and >> `local` overloads available in `opencl-c.h`? > > Yes, we could do this indeed as a clang extension. I don't think this will > impact the user code. However, this means vendors will have to add > definitions for extra overloads in OpenCL 2.0 mode? I wonder if making the `private`, `global`, and `local` overloads always available would even be considered an extension. Unless I overlooked something, I cannot find anything in the spec saying that the `private`, `global`, and `local` overloads should **not** be available when a `generic` overload is available (even though this is what Clang has always done)? Making all overloads always available in e.g. CL2.0 mode will indeed affect the generated calls, which means the definitions should be available when consuming the generated IR. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D107769/new/ https://reviews.llvm.org/D107769 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
