Anastasia added a comment. In https://reviews.llvm.org/D36410#863508, @yaxunl wrote:
> 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. Would it not be a problem generally though? Because private AS memory won't be accessed elsewhere and therefore if the block is enqueued to run on a different core or any place with different memory segment it would cause an issue... > I do not object to open a discussion at khronos to clarify this. Bug #16398 in case you would like to track it. Repository: rL LLVM https://reviews.llvm.org/D36410 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
