[PATCH] D69938: [OpenCL] Use __generic addr space when generating internal representation of lambda

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia added a comment.

In D69938#1755709 <https://reviews.llvm.org/D69938#1755709>, @rjmccall wrote:

> In D69938#1754894 <https://reviews.llvm.org/D69938#1754894>, @Anastasia wrote:
>
> > In D69938#1752024 <https://reviews.llvm.org/D69938#1752024>, @rjmccall wrote:
> >
> > > Yes, in that case copy-elision into the global variable is guaranteed.  You can write arbitrary expressions in global initializers, however, and those can use temporary lambdas.
> >
> >
> > I guess you mean something like this?
> >
> >   auto glambda = []() { return 1; }();
> >   
>
>
> Yes, or just passing it as an argument to something.
>
> > I don't see a way to change the address space of a lambda object however. It would only be possible to specify addr space qualifiers for a call operator of such lambdas.
>
> Yes, I think the language has to say what address space the lambda temporary is in.  Among other things, this can affect how captures are initialized, since some constructors are only usable in certain address spaces.  (Lambdas in global contexts can't capture surrounding local variables, but they can still have explicitly-initialized captures, like `[x=foo()] { ... }`.)  That language rule could be that lambda temporaries are always in the private address space, or it could be that lambdas in global contexts are in the global address space.  The latter might be easier because it's compatible with lifetime-extension: we don't necessarily know when processing the lambda whether its temporary will be lifetime-extended, and if it is, it needs to be in the global address space.  The only disadvantage of that is that we'd have to use global memory even for non-extended temporaries in global initializers.
>
> Richard might have thoughts about this.  I don't know if there's been any language work around copy-elision and/or lifetime-extension that might be stretchable to allow us to delay the address-space decision until later.


Ok, I see. Thanks! I agree for OpenCL `__global` might make more sense for the program scope lambdas. I will look into this. However, would it be ok to proceed with this patch adding `__generic` address space as a qualifier to lambda call operators by default. Is there anything that should be added to complete it?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69938/new/

https://reviews.llvm.org/D69938