maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/CodeGenCoroutines/coro-gro2.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

84 lines
2.5 KiB
C++
Raw Normal View History

[OpaquePtrs][Clang] Add -no-opaque-pointers to tests (NFC) This adds -no-opaque-pointers to clang tests whose output will change when opaque pointers are enabled by default. This is intended to be part of the migration approach described in https://discourse.llvm.org/t/enabling-opaque-pointers-by-default/61322/9. The patch has been produced by replacing %clang_cc1 with %clang_cc1 -no-opaque-pointers for tests that fail with opaque pointers enabled. Worth noting that this doesn't cover all tests, there's a remaining ~40 tests not using %clang_cc1 that will need a followup change. Differential Revision: https://reviews.llvm.org/D123115
2022-04-07 18:03:55 +08:00
// RUN: %clang_cc1 -no-opaque-pointers -triple x86_64-unknown-linux-gnu -fcoroutines-ts -std=c++20 -emit-llvm %s -o - -disable-llvm-passes | FileCheck %s
[coroutines] Fix application of NRVO to Coroutine "Gro" or return object. Summary: Fix NRVO for Gro variable. Previously, we only marked the GRO declaration as an NRVO variable when its QualType and the function return's QualType matched exactly (using operator==). However, this was incorrect for two reasons: 1. We were marking non-class types, such as ints, as being NRVO variables. 2. We failed to handle cases where the canonical types were the same, but the actual `QualType` objects were different. For example, if one was represented by a typedef. (Example: https://godbolt.org/g/3UFgsL) This patch fixes these bugs by marking the Gro variable as supporting NRVO only when `BuildReturnStmt` marks the Gro variable as a coroutine candidate. Reviewers: rsmith, GorNishanov, nicholas Reviewed By: GorNishanov Subscribers: majnemer, cfe-commits Differential Revision: https://reviews.llvm.org/D42343 llvm-svn: 324037
2018-02-02 07:47:54 +08:00
#include "Inputs/coroutine.h"
[Coroutines] [Frontend] Lookup in std namespace first Now in libcxx and clang, all the coroutine components are defined in std::experimental namespace. And now the coroutine TS is merged into C++20. So in the working draft like N4892, we could find the coroutine components is defined in std namespace instead of std::experimental namespace. And the coroutine support in clang seems to be relatively stable. So I think it may be suitable to move the coroutine component into the experiment namespace now. This patch would make clang lookup coroutine_traits in std namespace first. For the compatibility consideration, clang would lookup in std::experimental namespace if it can't find definitions in std namespace. So the existing codes wouldn't be break after update compiler. And in case the compiler found std::coroutine_traits and std::experimental::coroutine_traits at the same time, it would emit an error for it. The support for looking up std::experimental::coroutine_traits would be removed in Clang16. Reviewed By: lxfind, Quuxplusone Differential Revision: https://reviews.llvm.org/D108696
2021-11-04 11:50:30 +08:00
using namespace std;
[coroutines] Fix application of NRVO to Coroutine "Gro" or return object. Summary: Fix NRVO for Gro variable. Previously, we only marked the GRO declaration as an NRVO variable when its QualType and the function return's QualType matched exactly (using operator==). However, this was incorrect for two reasons: 1. We were marking non-class types, such as ints, as being NRVO variables. 2. We failed to handle cases where the canonical types were the same, but the actual `QualType` objects were different. For example, if one was represented by a typedef. (Example: https://godbolt.org/g/3UFgsL) This patch fixes these bugs by marking the Gro variable as supporting NRVO only when `BuildReturnStmt` marks the Gro variable as a coroutine candidate. Reviewers: rsmith, GorNishanov, nicholas Reviewed By: GorNishanov Subscribers: majnemer, cfe-commits Differential Revision: https://reviews.llvm.org/D42343 llvm-svn: 324037
2018-02-02 07:47:54 +08:00
namespace std {
struct nothrow_t {};
constexpr nothrow_t nothrow = {};
} // end namespace std
// Required when get_return_object_on_allocation_failure() is defined by
// the promise.
void* operator new(__SIZE_TYPE__ __sz, const std::nothrow_t&) noexcept;
void operator delete(void* __p, const std::nothrow_t&) noexcept;
template <class RetObject>
struct promise_type {
RetObject get_return_object();
suspend_always initial_suspend();
[Coroutines] Ensure co_await promise.final_suspend() does not throw Summary: This patch addresses https://bugs.llvm.org/show_bug.cgi?id=46256 The spec of coroutine requires that the expression co_­await promise.final_­suspend() shall not be potentially-throwing. To check this, we recursively look at every call (including Call, MemberCall, OperatorCall and Constructor) in all code generated by the final suspend, and ensure that the callees are declared with noexcept. We also look at any returned data type that requires explicit destruction, and check their destructors for noexcept. This patch does not check declarations with dependent types yet, which will be done in future patches. Updated all tests to add noexcept to the required functions, and added a dedicated test for this patch. This patch might start to cause existing codebase fail to compile because most people may not have been strict in tagging all the related functions noexcept. Reviewers: lewissbaker, modocache, junparser Reviewed By: modocache Subscribers: arphaman, junparser, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D82029
2020-06-16 07:27:41 +08:00
suspend_never final_suspend() noexcept;
[coroutines] Fix application of NRVO to Coroutine "Gro" or return object. Summary: Fix NRVO for Gro variable. Previously, we only marked the GRO declaration as an NRVO variable when its QualType and the function return's QualType matched exactly (using operator==). However, this was incorrect for two reasons: 1. We were marking non-class types, such as ints, as being NRVO variables. 2. We failed to handle cases where the canonical types were the same, but the actual `QualType` objects were different. For example, if one was represented by a typedef. (Example: https://godbolt.org/g/3UFgsL) This patch fixes these bugs by marking the Gro variable as supporting NRVO only when `BuildReturnStmt` marks the Gro variable as a coroutine candidate. Reviewers: rsmith, GorNishanov, nicholas Reviewed By: GorNishanov Subscribers: majnemer, cfe-commits Differential Revision: https://reviews.llvm.org/D42343 llvm-svn: 324037
2018-02-02 07:47:54 +08:00
void return_void();
static void unhandled_exception();
};
struct coro {
using promise_type = promise_type<coro>;
coro(coro const&);
struct Impl;
Impl *impl;
};
[C++20] [Coroutines] Implement return value optimization for get_return_object This patch tries to implement RVO for coroutine's return object got from get_return_object. From [dcl.fct.def.coroutine]/p7 we could know that the return value of get_return_object is either a reference or a prvalue. So it makes sense to do copy elision for the return value. The return object should be constructed directly into the storage where they would otherwise be copied/moved to. Test Plan: folly, check-all Reviewed By: junparser Differential revision: https://reviews.llvm.org/D117087
2022-01-10 19:18:33 +08:00
// Verify that the RVO is applied.
[Clang/Test]: Rename enable_noundef_analysis to disable-noundef-analysis and turn it off by default Turning on `enable_noundef_analysis` flag allows better codegen by removing freeze instructions. I modified clang by renaming `enable_noundef_analysis` flag to `disable-noundef-analysis` and turning it off by default. Test updates are made as a separate patch: D108453 Reviewed By: eugenis Differential Revision: https://reviews.llvm.org/D105169
2022-01-16 17:53:11 +08:00
// CHECK-LABEL: define{{.*}} void @_Z1fi(%struct.coro* noalias sret(%struct.coro) align 8 %agg.result, i32 noundef %0)
[coroutines] Fix application of NRVO to Coroutine "Gro" or return object. Summary: Fix NRVO for Gro variable. Previously, we only marked the GRO declaration as an NRVO variable when its QualType and the function return's QualType matched exactly (using operator==). However, this was incorrect for two reasons: 1. We were marking non-class types, such as ints, as being NRVO variables. 2. We failed to handle cases where the canonical types were the same, but the actual `QualType` objects were different. For example, if one was represented by a typedef. (Example: https://godbolt.org/g/3UFgsL) This patch fixes these bugs by marking the Gro variable as supporting NRVO only when `BuildReturnStmt` marks the Gro variable as a coroutine candidate. Reviewers: rsmith, GorNishanov, nicholas Reviewed By: GorNishanov Subscribers: majnemer, cfe-commits Differential Revision: https://reviews.llvm.org/D42343 llvm-svn: 324037
2018-02-02 07:47:54 +08:00
coro f(int) {
[Clang/Test]: Rename enable_noundef_analysis to disable-noundef-analysis and turn it off by default Turning on `enable_noundef_analysis` flag allows better codegen by removing freeze instructions. I modified clang by renaming `enable_noundef_analysis` flag to `disable-noundef-analysis` and turning it off by default. Test updates are made as a separate patch: D108453 Reviewed By: eugenis Differential Revision: https://reviews.llvm.org/D105169
2022-01-16 17:53:11 +08:00
// CHECK: %call = call noalias noundef nonnull i8* @_Znwm(
[coroutines] Fix application of NRVO to Coroutine "Gro" or return object. Summary: Fix NRVO for Gro variable. Previously, we only marked the GRO declaration as an NRVO variable when its QualType and the function return's QualType matched exactly (using operator==). However, this was incorrect for two reasons: 1. We were marking non-class types, such as ints, as being NRVO variables. 2. We failed to handle cases where the canonical types were the same, but the actual `QualType` objects were different. For example, if one was represented by a typedef. (Example: https://godbolt.org/g/3UFgsL) This patch fixes these bugs by marking the Gro variable as supporting NRVO only when `BuildReturnStmt` marks the Gro variable as a coroutine candidate. Reviewers: rsmith, GorNishanov, nicholas Reviewed By: GorNishanov Subscribers: majnemer, cfe-commits Differential Revision: https://reviews.llvm.org/D42343 llvm-svn: 324037
2018-02-02 07:47:54 +08:00
// CHECK-NEXT: br label %[[CoroInit:.*]]
// CHECK: {{.*}}[[CoroInit]]:
Reapply "OpaquePtr: Add type to sret attribute" This reverts commit eb9f7c28e5fe6d75fed3587023e17f2997c8024b. Previously this was incorrectly handling linking of the contained type, so this merges the fixes from D88973.
2020-09-29 21:33:55 +08:00
// CHECK: call void @{{.*get_return_objectEv}}(%struct.coro* sret(%struct.coro) align 8 %agg.result
[C++20] [Coroutines] Implement return value optimization for get_return_object This patch tries to implement RVO for coroutine's return object got from get_return_object. From [dcl.fct.def.coroutine]/p7 we could know that the return value of get_return_object is either a reference or a prvalue. So it makes sense to do copy elision for the return value. The return object should be constructed directly into the storage where they would otherwise be copied/moved to. Test Plan: folly, check-all Reviewed By: junparser Differential revision: https://reviews.llvm.org/D117087
2022-01-10 19:18:33 +08:00
co_return;
[coroutines] Fix application of NRVO to Coroutine "Gro" or return object. Summary: Fix NRVO for Gro variable. Previously, we only marked the GRO declaration as an NRVO variable when its QualType and the function return's QualType matched exactly (using operator==). However, this was incorrect for two reasons: 1. We were marking non-class types, such as ints, as being NRVO variables. 2. We failed to handle cases where the canonical types were the same, but the actual `QualType` objects were different. For example, if one was represented by a typedef. (Example: https://godbolt.org/g/3UFgsL) This patch fixes these bugs by marking the Gro variable as supporting NRVO only when `BuildReturnStmt` marks the Gro variable as a coroutine candidate. Reviewers: rsmith, GorNishanov, nicholas Reviewed By: GorNishanov Subscribers: majnemer, cfe-commits Differential Revision: https://reviews.llvm.org/D42343 llvm-svn: 324037
2018-02-02 07:47:54 +08:00
}
template <class RetObject>
struct promise_type_with_on_alloc_failure {
static RetObject get_return_object_on_allocation_failure();
RetObject get_return_object();
suspend_always initial_suspend();
[Coroutines] Ensure co_await promise.final_suspend() does not throw Summary: This patch addresses https://bugs.llvm.org/show_bug.cgi?id=46256 The spec of coroutine requires that the expression co_­await promise.final_­suspend() shall not be potentially-throwing. To check this, we recursively look at every call (including Call, MemberCall, OperatorCall and Constructor) in all code generated by the final suspend, and ensure that the callees are declared with noexcept. We also look at any returned data type that requires explicit destruction, and check their destructors for noexcept. This patch does not check declarations with dependent types yet, which will be done in future patches. Updated all tests to add noexcept to the required functions, and added a dedicated test for this patch. This patch might start to cause existing codebase fail to compile because most people may not have been strict in tagging all the related functions noexcept. Reviewers: lewissbaker, modocache, junparser Reviewed By: modocache Subscribers: arphaman, junparser, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D82029
2020-06-16 07:27:41 +08:00
suspend_never final_suspend() noexcept;
[coroutines] Fix application of NRVO to Coroutine "Gro" or return object. Summary: Fix NRVO for Gro variable. Previously, we only marked the GRO declaration as an NRVO variable when its QualType and the function return's QualType matched exactly (using operator==). However, this was incorrect for two reasons: 1. We were marking non-class types, such as ints, as being NRVO variables. 2. We failed to handle cases where the canonical types were the same, but the actual `QualType` objects were different. For example, if one was represented by a typedef. (Example: https://godbolt.org/g/3UFgsL) This patch fixes these bugs by marking the Gro variable as supporting NRVO only when `BuildReturnStmt` marks the Gro variable as a coroutine candidate. Reviewers: rsmith, GorNishanov, nicholas Reviewed By: GorNishanov Subscribers: majnemer, cfe-commits Differential Revision: https://reviews.llvm.org/D42343 llvm-svn: 324037
2018-02-02 07:47:54 +08:00
void return_void();
static void unhandled_exception();
};
struct coro_two {
using promise_type = promise_type_with_on_alloc_failure<coro_two>;
coro_two(coro_two const&);
struct Impl;
Impl *impl;
};
[C++20] [Coroutines] Implement return value optimization for get_return_object This patch tries to implement RVO for coroutine's return object got from get_return_object. From [dcl.fct.def.coroutine]/p7 we could know that the return value of get_return_object is either a reference or a prvalue. So it makes sense to do copy elision for the return value. The return object should be constructed directly into the storage where they would otherwise be copied/moved to. Test Plan: folly, check-all Reviewed By: junparser Differential revision: https://reviews.llvm.org/D117087
2022-01-10 19:18:33 +08:00
// Verify that the RVO is applied.
[Clang/Test]: Rename enable_noundef_analysis to disable-noundef-analysis and turn it off by default Turning on `enable_noundef_analysis` flag allows better codegen by removing freeze instructions. I modified clang by renaming `enable_noundef_analysis` flag to `disable-noundef-analysis` and turning it off by default. Test updates are made as a separate patch: D108453 Reviewed By: eugenis Differential Revision: https://reviews.llvm.org/D105169
2022-01-16 17:53:11 +08:00
// CHECK-LABEL: define{{.*}} void @_Z1hi(%struct.coro_two* noalias sret(%struct.coro_two) align 8 %agg.result, i32 noundef %0)
[C++20] [Coroutines] Implement return value optimization for get_return_object This patch tries to implement RVO for coroutine's return object got from get_return_object. From [dcl.fct.def.coroutine]/p7 we could know that the return value of get_return_object is either a reference or a prvalue. So it makes sense to do copy elision for the return value. The return object should be constructed directly into the storage where they would otherwise be copied/moved to. Test Plan: folly, check-all Reviewed By: junparser Differential revision: https://reviews.llvm.org/D117087
2022-01-10 19:18:33 +08:00
coro_two h(int) {
[coroutines] Fix application of NRVO to Coroutine "Gro" or return object. Summary: Fix NRVO for Gro variable. Previously, we only marked the GRO declaration as an NRVO variable when its QualType and the function return's QualType matched exactly (using operator==). However, this was incorrect for two reasons: 1. We were marking non-class types, such as ints, as being NRVO variables. 2. We failed to handle cases where the canonical types were the same, but the actual `QualType` objects were different. For example, if one was represented by a typedef. (Example: https://godbolt.org/g/3UFgsL) This patch fixes these bugs by marking the Gro variable as supporting NRVO only when `BuildReturnStmt` marks the Gro variable as a coroutine candidate. Reviewers: rsmith, GorNishanov, nicholas Reviewed By: GorNishanov Subscribers: majnemer, cfe-commits Differential Revision: https://reviews.llvm.org/D42343 llvm-svn: 324037
2018-02-02 07:47:54 +08:00
[C++20] [Coroutines] Implement return value optimization for get_return_object This patch tries to implement RVO for coroutine's return object got from get_return_object. From [dcl.fct.def.coroutine]/p7 we could know that the return value of get_return_object is either a reference or a prvalue. So it makes sense to do copy elision for the return value. The return object should be constructed directly into the storage where they would otherwise be copied/moved to. Test Plan: folly, check-all Reviewed By: junparser Differential revision: https://reviews.llvm.org/D117087
2022-01-10 19:18:33 +08:00
// CHECK: %call = call noalias noundef i8* @_ZnwmRKSt9nothrow_t
// CHECK-NEXT: %[[CheckNull:.*]] = icmp ne i8* %call, null
// CHECK-NEXT: br i1 %[[CheckNull]], label %[[InitOnSuccess:.*]], label %[[InitOnFailure:.*]]
[coroutines] Fix application of NRVO to Coroutine "Gro" or return object. Summary: Fix NRVO for Gro variable. Previously, we only marked the GRO declaration as an NRVO variable when its QualType and the function return's QualType matched exactly (using operator==). However, this was incorrect for two reasons: 1. We were marking non-class types, such as ints, as being NRVO variables. 2. We failed to handle cases where the canonical types were the same, but the actual `QualType` objects were different. For example, if one was represented by a typedef. (Example: https://godbolt.org/g/3UFgsL) This patch fixes these bugs by marking the Gro variable as supporting NRVO only when `BuildReturnStmt` marks the Gro variable as a coroutine candidate. Reviewers: rsmith, GorNishanov, nicholas Reviewed By: GorNishanov Subscribers: majnemer, cfe-commits Differential Revision: https://reviews.llvm.org/D42343 llvm-svn: 324037
2018-02-02 07:47:54 +08:00
[C++20] [Coroutines] Implement return value optimization for get_return_object This patch tries to implement RVO for coroutine's return object got from get_return_object. From [dcl.fct.def.coroutine]/p7 we could know that the return value of get_return_object is either a reference or a prvalue. So it makes sense to do copy elision for the return value. The return object should be constructed directly into the storage where they would otherwise be copied/moved to. Test Plan: folly, check-all Reviewed By: junparser Differential revision: https://reviews.llvm.org/D117087
2022-01-10 19:18:33 +08:00
// CHECK: {{.*}}[[InitOnFailure]]:
// CHECK-NEXT: call void @{{.*get_return_object_on_allocation_failureEv}}(%struct.coro_two* sret(%struct.coro_two) align 8 %agg.result
// CHECK-NEXT: br label %[[RetLabel:.*]]
[coroutines] Fix application of NRVO to Coroutine "Gro" or return object. Summary: Fix NRVO for Gro variable. Previously, we only marked the GRO declaration as an NRVO variable when its QualType and the function return's QualType matched exactly (using operator==). However, this was incorrect for two reasons: 1. We were marking non-class types, such as ints, as being NRVO variables. 2. We failed to handle cases where the canonical types were the same, but the actual `QualType` objects were different. For example, if one was represented by a typedef. (Example: https://godbolt.org/g/3UFgsL) This patch fixes these bugs by marking the Gro variable as supporting NRVO only when `BuildReturnStmt` marks the Gro variable as a coroutine candidate. Reviewers: rsmith, GorNishanov, nicholas Reviewed By: GorNishanov Subscribers: majnemer, cfe-commits Differential Revision: https://reviews.llvm.org/D42343 llvm-svn: 324037
2018-02-02 07:47:54 +08:00
[C++20] [Coroutines] Implement return value optimization for get_return_object This patch tries to implement RVO for coroutine's return object got from get_return_object. From [dcl.fct.def.coroutine]/p7 we could know that the return value of get_return_object is either a reference or a prvalue. So it makes sense to do copy elision for the return value. The return object should be constructed directly into the storage where they would otherwise be copied/moved to. Test Plan: folly, check-all Reviewed By: junparser Differential revision: https://reviews.llvm.org/D117087
2022-01-10 19:18:33 +08:00
// CHECK: {{.*}}[[InitOnSuccess]]:
// CHECK: call void @{{.*get_return_objectEv}}(%struct.coro_two* sret(%struct.coro_two) align 8 %agg.result
[coroutines] Fix application of NRVO to Coroutine "Gro" or return object. Summary: Fix NRVO for Gro variable. Previously, we only marked the GRO declaration as an NRVO variable when its QualType and the function return's QualType matched exactly (using operator==). However, this was incorrect for two reasons: 1. We were marking non-class types, such as ints, as being NRVO variables. 2. We failed to handle cases where the canonical types were the same, but the actual `QualType` objects were different. For example, if one was represented by a typedef. (Example: https://godbolt.org/g/3UFgsL) This patch fixes these bugs by marking the Gro variable as supporting NRVO only when `BuildReturnStmt` marks the Gro variable as a coroutine candidate. Reviewers: rsmith, GorNishanov, nicholas Reviewed By: GorNishanov Subscribers: majnemer, cfe-commits Differential Revision: https://reviews.llvm.org/D42343 llvm-svn: 324037
2018-02-02 07:47:54 +08:00
[C++20] [Coroutines] Implement return value optimization for get_return_object This patch tries to implement RVO for coroutine's return object got from get_return_object. From [dcl.fct.def.coroutine]/p7 we could know that the return value of get_return_object is either a reference or a prvalue. So it makes sense to do copy elision for the return value. The return object should be constructed directly into the storage where they would otherwise be copied/moved to. Test Plan: folly, check-all Reviewed By: junparser Differential revision: https://reviews.llvm.org/D117087
2022-01-10 19:18:33 +08:00
// CHECK: [[RetLabel]]:
// CHECK-NEXT: ret void
[coroutines] Fix application of NRVO to Coroutine "Gro" or return object. Summary: Fix NRVO for Gro variable. Previously, we only marked the GRO declaration as an NRVO variable when its QualType and the function return's QualType matched exactly (using operator==). However, this was incorrect for two reasons: 1. We were marking non-class types, such as ints, as being NRVO variables. 2. We failed to handle cases where the canonical types were the same, but the actual `QualType` objects were different. For example, if one was represented by a typedef. (Example: https://godbolt.org/g/3UFgsL) This patch fixes these bugs by marking the Gro variable as supporting NRVO only when `BuildReturnStmt` marks the Gro variable as a coroutine candidate. Reviewers: rsmith, GorNishanov, nicholas Reviewed By: GorNishanov Subscribers: majnemer, cfe-commits Differential Revision: https://reviews.llvm.org/D42343 llvm-svn: 324037
2018-02-02 07:47:54 +08:00
co_return;
}