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

[Yaxun Liu via Phabricator via cfe-commits]

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