yuxuanchen1997 wrote: > What I thought is, to touch the code that generates the CallExpr specially > instead of marking a CallExpr as special after that. The later generally > looks not good to me.
The recursive structure in `EmitCallExpr` makes it hard to do this. There are just too many ways you can emit a CallExpr via `EmitCallExpr`. > For the later question, I roughly remember we can make it in several > functions emitting CallExpr in CGExpr.cpp and CGExprCXX.cpp. As far as I can tell, it's just the `CallOrInvoke` out parameter. What I have done was to just apply it all the way to the top level `EmitCallExpr`? > Also we should try to avoid touch so many CodeGen* files if possible. It > looks scary at first and not easy to maintain. It is a little scary to do this at first, and there are cases like Pseudo destructors that don't end up being a Call or Invoke instruction. I still think this is easier to maintain than having `EmitCall` somehow know the context that this is a coroutine we can elide and do the marking there. > It may be possible either due to new operator co_await overloads This we can check in the FE if the operator co_await we found was a member of the attributed type? If the search resulted in a nonmember operator we don't do the optimization? > or due to the other await_transform didn't handle third party coroutine types > well. Indeed. The general assumption is that if you do something in the await_transform to break the promise to the compiler, it should be obvious to the developer. > So may be, if possible, I feel better if we can add the attribute to awaiters. That's also an option. The main conflict there being: https://github.com/llvm/llvm-project/pull/94693 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
