rjmccall added a reviewer: rsmith. rjmccall added a comment. 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. 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
