yaxunl added a comment. In https://reviews.llvm.org/D36410#863579, @Anastasia wrote:
> 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... The block context can be passed to the kernel directly. In this case it ends up in the stack of the callee and takes private address space. > > >> 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
