[clang] [llvm] [Clang] C++20 Coroutines: Introduce Frontend Attribute [[clang::coro_await_elidable]] (PR #99282)

Yuxuan Chen via cfe-commits cfe-commits at lists.llvm.org
Wed Aug 7 09:19:09 PDT 2024


================
@@ -5443,24 +5444,38 @@ RValue CodeGenFunction::EmitRValueForField(LValue LV,
 //===--------------------------------------------------------------------===//
 
 RValue CodeGenFunction::EmitCallExpr(const CallExpr *E,
-                                     ReturnValueSlot ReturnValue) {
+                                     ReturnValueSlot ReturnValue,
+                                     llvm::CallBase **CallOrInvoke) {
+  llvm::CallBase *CallOrInvokeStorage;
+  if (!CallOrInvoke) {
+    CallOrInvoke = &CallOrInvokeStorage;
+  }
+
+  auto AddCoroMustElideOnExit = llvm::make_scope_exit([&] {
+    if (E->isCoroMustElide()) {
+      auto *I = *CallOrInvoke;
+      if (I)
+        I->addFnAttr(llvm::Attribute::CoroMustElide);
----------------
yuxuanchen1997 wrote:

> I am wondering if all of the Emit*CallExpr function will be converged to one

This actually sounds like a bigger change to me. If you search for all the usages of `Emit*CallExpr`, most of them are called from `EmitCallExpr` at the top level. (with the exception of `EmitSimpleCallExpr`, whose usage is really limited, maybe questionable here as well.)

> a few fundamental functions to emit the CallInst like EmitCall then we can do our job there

EmitCall doesn't currently take a `CallExpr`, wondering if you'd like me to change to adding a flag to propagate this information. It also has multiple overloads, and perhaps more importantly existing call also using `CallOrInvoke` from `EmitCall` to ["do something"](https://github.com/llvm/llvm-project/blob/97743b8be86ab96afb26ba93e1876406c1f4d541/clang/lib/CodeGen/CGExpr.cpp#L6034-L6048). So I am not sure how this perspective will actually pan out once put into code. 

https://github.com/llvm/llvm-project/pull/99282


More information about the cfe-commits mailing list