[PATCH] D118605: [OpenCL] Add support of language builtins for OpenCL C 3.0

Anastasia Stulova via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Thu Feb 10 02:39:49 PST 2022

Anastasia added inline comments.

Comment at: clang/lib/Basic/Builtins.cpp:79
+  bool OclBlocksUnsupported =
+      (LangOpts.getOpenCLCompatibleVersion() < 200 || !LangOpts.Blocks) &&
+      (BuiltinInfo.Langs & OCL_BLOCKS);
svenvh wrote:
> azabaznov wrote:
> > This check is needed as //-cl-std=CL1.2// can be used together with //-fblocks//. But in 3.0 block support requires //__opencl_c_device_enqueue// feature.
> > This check is needed as -cl-std=CL1.2 can be used together with -fblocks.
> That surprised me, I cannot find anything in the OpenCL 1.2 spec about this. @Anastasia do you know if this is an (undocumented?) Clang extension?
> There are tests checking for this (e.g. `clang/test/Frontend/opencl.cl`), so we need this check to preserve the existing behavior indeed.
I think blocks is a clang language feature that can be enabled using `-fblocks` and activate extra functionality of blocks used as lambda only in C-based languages. But the `enqueue_kernel` is only supported from OpenCL 2.0 onwards since it requires functionality outside of frontend so I think this check is reasonable. I feel perhaps we should rename to something like:


Since the builtins are not about blocks but about enqueueing kernels from device...

Also I would suggest a comment explaining that we check for `Blocks` because it is coupled with enqueue kernel functionality.

  rG LLVM Github Monorepo



More information about the cfe-commits mailing list