[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