[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