[PATCH] D36410: [OpenCL] Handle taking address of block captures

[Anastasia Stulova via Phabricator via cfe-commits]

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