[PATCH] D137872: Implement lambdas with inalloca parameters by forwarding to function without inalloca calling convention.
Amy Huang via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Wed Jun 14 11:21:11 PDT 2023
akhuang added inline comments.
================
Comment at: clang/lib/CodeGen/CGClass.cpp:3097
+ FD->getLocation(), FD->getLocation());
+ CGF.EmitFunctionBody(FD->getBody());
+ CGF.FinishFunction();
----------------
efriedma wrote:
> Is there any way we can use GenerateCode as the entrypoint here, instead of calling EmitFunctionBody directly? Without this patch, EmitFunctionBody has exactly one caller, so this makes the control flow and special cases more complicated to reason about. For example, there's some special coroutine handling in GenerateCode.
Changed to using GenerateCode -- had to add another case to the path in GenerateCode to make sure we emit different things for the call op body inside __impl and the call op body inside the call op function.
================
Comment at: clang/lib/CodeGen/CodeGenFunction.cpp:1472
+ // the call operator body.
+ EmitLambdaStaticInvokeBody(cast<CXXMethodDecl>(FD));
} else if (FD->isDefaulted() && isa<CXXMethodDecl>(FD) &&
----------------
efriedma wrote:
> Does this pass the correct value of "this"? EmitLambdaStaticInvokeBody creates a new alloca to represent "this", but it's already an argument to the function.
>
> Granted, it only matters in really obscure cases, but still.
That's true, the "this" won't be passed correctly.
Actually, would it be fine to just emit the original call op body? (so that the same function body is emitted twice -- once in the call op and once in __impl).
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D137872/new/
https://reviews.llvm.org/D137872
More information about the cfe-commits
mailing list