[PATCH] D136998: Try to implement lambdas with inalloca parameters by inlining the call operator function.

Eli Friedman via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Mon Nov 14 16:30:52 PST 2022


efriedma added a comment.

In D136998#3926321 <https://reviews.llvm.org/D136998#3926321>, @rnk wrote:

> In D136998#3906874 <https://reviews.llvm.org/D136998#3906874>, @efriedma wrote:
>
>> Should we try to use this codepath for variadic lambdas as well?
>
> Yes!
>
>> Do we want to try to unify our cloning code?  CodeGenFunction::GenerateVarArgsThunk has code doing something similar.  (It's at least worth comparing to see if you're doing something significantly different...)
>
> Good idea
>
> In D136998#3906881 <https://reviews.llvm.org/D136998#3906881>, @efriedma wrote:
>
>> Might also be worth considering if we can avoid cloning here.  It should be possible to emit the lambda body into a separate function with a calling convention of your choice, and make both the call operator and the static invoker call it.
>
> This would be nice. I wasn't able to provide guidance on how to do that, and I think Amy was struggling to synthesize a new method (`__invoke`, `__impl`) at the AST layer.

I think you wouldn't actually synthesize it at all in the AST.

Basically, the follow code changes:

1. Change the mangling of the function that contains the actual lambda body.
2. Make that function use an alternate calling convention that doesn't involve inalloca etc.
3. Synthesize thunks to represent the actual call operator and static invoker.

This is similar to the way virtual overriding works: there's an actual function, but there are also alternate entry points that end up in the vtables.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136998



More information about the cfe-commits mailing list