yaxunl added a comment. In https://reviews.llvm.org/D36410#863426, @Anastasia wrote:
> In https://reviews.llvm.org/D36410#863409, @yaxunl wrote: > > > LGTM as a temporary measure until we have a solution for properly emitting > > blocks as enqueued kernel. > > > Should I start discussion with Khronos on that? What would our preference be > - implicitly `generic` AS for capture addresses? I had a discussion with Brian and we realized that captured variable in global address space is kind of unusual since that means each work item needs to have a different global pointer as the block context argument to the kernel, whereas usually when you set global pointer kernel argument for a kernel, different work items get the same global pointer. However, we cannot totally rule out an implementation of enqueue_kernel like that. That said, I kind of think the address space of captured variable is implementation dependent, though normally it seems private address space makes more sense. I do not object to open a discussion at khronos to clarify this. https://reviews.llvm.org/D36410 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
