rjmccall added a comment. In D76620#2327988 <https://reviews.llvm.org/D76620#2327988>, @erichkeane wrote:
> In D76620#2327976 <https://reviews.llvm.org/D76620#2327976>, @rjmccall wrote: > >> In D76620#2327910 <https://reviews.llvm.org/D76620#2327910>, @erichkeane >> wrote: >> >>> In D76620#2327901 <https://reviews.llvm.org/D76620#2327901>, @rjmccall >>> wrote: >>> >>>> You know on both sides that a lambda is used as a kernel, yes? Why not >>>> simply introduce that into the mangling of lambdas, so that the subset of >>>> lambdas used as kernels form a stable sequence? >>> >>> Coming up with said stable sequence is somewhat difficult as well. A >>> strict integer ordering didn't end up being stable, as some of the kernel >>> handling can cause instantiations to happen in a slightly different >>> ordering, which messed that up, as would use of the builtin. We wanted to >>> find a way that was dependent on the source code alone. The "Quick and >>> Dirty" solution was line/column numbers, though we considered a hash of >>> that same information to at least make it shorter. >> >> Certainly you wouldn't want a *global* sequence ID. However, lambdas can't >> just occur globally, they're always part of some declaration that they can >> be scoped to, so that you have e.g. "the third kernel lambda within function >> X". I fail to see how that wouldn't address the concern about instantiation >> order, and it's still source-directed. > > Hmm... I'll have to consider that. That is an interesting thought. > Presumably we could just copy the 'getLambdaManglingNumber' stuff in that > case, and place the value in the same location in the mangling, with some > sort of discriminator (to avoid conflicting manglings). The Itanium mangling already produces a different lambda mangling number for different lambda signatures. You just need the kernel-ness to be part of the signature. > The only other concern I have is WHEN we know that a lambda is used in a > kernel, which we don't until it is called (and can cause confusion when it is > a template parameter and called later). Oh, yes, if you don't know that a lambda is used as a kernel locally then this falls apart a bit. You could of course pretend for ABI purposes that there's a new intermediate lambda at the kernel use point when the lambda is not local to the current function. I don't think there's anything which relies on mangling lambdas before the function they're contained within is fully type-checked. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D76620/new/ https://reviews.llvm.org/D76620 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
