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



_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to