[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