[PATCH] D145641: [Coroutines] Implement fix for cwg2563 issue and enable RVO under certain conditions

Chuanqi Xu via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed Mar 15 19:23:12 PDT 2023


ChuanqiXu added inline comments.


================
Comment at: clang/lib/CodeGen/CGCoroutine.cpp:500-508
+    DirectEmit = [&]() {
+      auto *RVI = S.getReturnValueInit();
+      if (!RVI || CGF.FnRetTy->isVoidType())
+        return true;
+      auto GroType = RVI->getType();
+      if (GroType->isVoidType())
+        return true;
----------------
bruno wrote:
> ChuanqiXu wrote:
> > What's the case about returning void and the return_object type is different from the returning type?
> In that case we do `DirectEmit` since there's no reason to delay initialization, am I missing something?
I mean it looks invalid if the function returns void and the return_object_type returns a non-void type. So we can judge this by `hasSameType()` directly.


================
Comment at: clang/test/SemaCXX/coroutine-no-move-ctor.cpp:24-26
 invoker f() {
   co_return;
 }
----------------
bruno wrote:
> ChuanqiXu wrote:
> > How about adding a failing case that the types are not matched?
> I'm having trouble crafting one. I extracted similar examples from other testcases and even though I can confirm they correctly apply delayed initialization, they don't require copies (usually directly call conversion operators or similar) and we don't trigger the reverse usecase, do you have one testcase in mind I could use?
Oh, I don't have an existing test. Although not the best, maybe you can try to emit the codes to LLVM IR and match that.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D145641/new/

https://reviews.llvm.org/D145641



More information about the cfe-commits mailing list