https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/84285
>From 48b3261e1d217b7ce78180314a222dca4d6aba18 Mon Sep 17 00:00:00 2001
From: Chuanqi Xu
Date: Thu, 7 Mar 2024 15:19:28 +0800
Subject: [PATCH 1/5] [NFC] [C++20] [Modules] [P1689] [Scanner] Don't use
thread
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/84285
>From 48b3261e1d217b7ce78180314a222dca4d6aba18 Mon Sep 17 00:00:00 2001
From: Chuanqi Xu
Date: Thu, 7 Mar 2024 15:19:28 +0800
Subject: [PATCH 1/4] [NFC] [C++20] [Modules] [P1689] [Scanner] Don't use
thread
@@ -744,6 +744,9 @@ getCompilationDataBase(int argc, char **argv, std::string
) {
return nullptr;
}
+ // Only 1 threads is required if P1689 per file mode.
+ NumThreads = 1;
ChuanqiXu9 wrote:
Oh, sorry. I don't know why I missed this somehow. This
ChuanqiXu9 wrote:
> > ClangGetUsedFilesFromModulesPlugin
>
> This has a hole where if a currently-unused file is not listed, but it is
> changed in such a way that it now matters (e.g., it changes include order,
> adds/removes includes, etc.), we need to recompile consumers.
>
> > what
ChuanqiXu9 wrote:
> @ChuanqiXu9 since you suggested this test approach
It looks like that I failed to understand VE is under X86 also...
> do you know whether this is the expected behavior of -sysroot ?
I am not sure. This is surprising to me too.
> The point is to build libraries and test
Author: Chuanqi Xu
Date: 2024-03-11T17:02:43+08:00
New Revision: 0f501c30b9601627c236f9abca8a3befba5dc161
URL:
https://github.com/llvm/llvm-project/commit/0f501c30b9601627c236f9abca8a3befba5dc161
DIFF:
https://github.com/llvm/llvm-project/commit/0f501c30b9601627c236f9abca8a3befba5dc161.diff
ChuanqiXu9 wrote:
This commit breaks our coroutines library async_simple
`https://github.com/alibaba/async_simple` and here is a (relative) minimal
reproducer: https://godbolt.org/z/sG5jzcGEz
The reproducer comes from an implementation for async_simple::Generator
Author: Chuanqi Xu
Date: 2024-03-11T11:39:21+08:00
New Revision: 3f6bc1adf805681293c2ef0b93b708ff52244c00
URL:
https://github.com/llvm/llvm-project/commit/3f6bc1adf805681293c2ef0b93b708ff52244c00
DIFF:
https://github.com/llvm/llvm-project/commit/3f6bc1adf805681293c2ef0b93b708ff52244c00.diff
https://github.com/ChuanqiXu9 closed
https://github.com/llvm/llvm-project/pull/79712
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
ChuanqiXu9 wrote:
I'll merge this since I find you may not have commit access.
https://github.com/llvm/llvm-project/pull/79712
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ChuanqiXu9 approved this pull request.
LGTM.
https://github.com/llvm/llvm-project/pull/84519
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ChuanqiXu9 approved this pull request.
LGTM then. Thanks.
https://github.com/llvm/llvm-project/pull/79712
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/84285
>From dd9711be2368a299b408d0ff06ec9c1c0540083b Mon Sep 17 00:00:00 2001
From: Chuanqi Xu
Date: Thu, 7 Mar 2024 15:19:28 +0800
Subject: [PATCH 1/3] [NFC] [C++20] [Modules] [P1689] [Scanner] Don't use
thread
@@ -893,102 +889,118 @@ int clang_scan_deps_main(int argc, char **argv, const
llvm::ToolContext &) {
if (Format == ScanningOutputFormat::Full)
FD.emplace(ModuleName.empty() ? Inputs.size() : 0);
- if (Verbose) {
-llvm::outs() << "Running clang-scan-deps on " <<
@@ -893,102 +889,118 @@ int clang_scan_deps_main(int argc, char **argv, const
llvm::ToolContext &) {
if (Format == ScanningOutputFormat::Full)
FD.emplace(ModuleName.empty() ? Inputs.size() : 0);
- if (Verbose) {
-llvm::outs() << "Running clang-scan-deps on " <<
@@ -744,6 +744,9 @@ getCompilationDataBase(int argc, char **argv, std::string
) {
return nullptr;
}
+ // Only 1 threads is required if P1689 per file mode.
+ NumThreads = 1;
ChuanqiXu9 wrote:
Makes sense. Done.
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/84285
>From dd9711be2368a299b408d0ff06ec9c1c0540083b Mon Sep 17 00:00:00 2001
From: Chuanqi Xu
Date: Thu, 7 Mar 2024 15:19:28 +0800
Subject: [PATCH 1/2] [NFC] [C++20] [Modules] [P1689] [Scanner] Don't use
thread
https://github.com/ChuanqiXu9 closed
https://github.com/llvm/llvm-project/pull/75894
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ChuanqiXu9 created
https://github.com/llvm/llvm-project/pull/84285
I suddenly found that the clang scan deps may use all concurrent threads to
scan the files. It makes sense in the batch mode. But in P1689 per file mode,
it simply wastes times and resources.
This patch
@@ -6898,10 +6898,18 @@ class Sema final {
BinaryOperatorKind Operator);
ActOnCXXThis - Parse 'this' pointer.
- ExprResult ActOnCXXThis(SourceLocation loc);
+ ///
+ /// \param SkipLambdaCaptureCheck Whether to skip the 'this'
https://github.com/ChuanqiXu9 approved this pull request.
LGTM with the adding the comments.
https://github.com/llvm/llvm-project/pull/84193
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
@@ -6898,10 +6898,18 @@ class Sema final {
BinaryOperatorKind Operator);
ActOnCXXThis - Parse 'this' pointer.
- ExprResult ActOnCXXThis(SourceLocation loc);
+ ///
+ /// \param SkipLambdaCaptureCheck Whether to skip the 'this'
@@ -6898,10 +6898,18 @@ class Sema final {
BinaryOperatorKind Operator);
ActOnCXXThis - Parse 'this' pointer.
- ExprResult ActOnCXXThis(SourceLocation loc);
+ ///
+ /// \param SkipLambdaCaptureCheck Whether to skip the 'this'
ChuanqiXu9 wrote:
> Can we add a release note and documentation for this? Thanks!
The current patch is transparent to users and it is only part of the series
patches. I'd like to document that after I made the series of patches.
https://github.com/llvm/llvm-project/pull/75894
Author: Chuanqi Xu
Date: 2024-03-06T15:46:55+08:00
New Revision: d3df2a834cf6febb44c699d109b9e7f622194837
URL:
https://github.com/llvm/llvm-project/commit/d3df2a834cf6febb44c699d109b9e7f622194837
DIFF:
https://github.com/llvm/llvm-project/commit/d3df2a834cf6febb44c699d109b9e7f622194837.diff
ChuanqiXu9 wrote:
I am going to land this in the week later if no objections come in. I think it
is necessary to land the series of patches (to reduce the contents of BMI) for
clang19. And of course, the functionality will be opt in for one~two releases
for experimental.
ChuanqiXu9 wrote:
> Do you expect to make any changes to type streaming?
I don't expect to do that explicitly. The number of types deserialized can be
decreased naturally after we avoid emitting declarations during the writing.
https://github.com/llvm/llvm-project/pull/75894
@@ -830,6 +843,19 @@ class PCHGenerator : public SemaConsumer {
bool hasEmittedPCH() const { return Buffer->IsComplete; }
};
+class ReducedBMIGenerator : public PCHGenerator {
+public:
+ ReducedBMIGenerator(const Preprocessor , InMemoryModuleCache ,
+
ChuanqiXu9 wrote:
> * I do not want to block progress, so let's move forward with this patch for
> now.
Yeah. Great to see we have some progress finally. I think this is really
important since I see more and more peope complaninig the performance for
modules. I feel this series patch is key
ChuanqiXu9 wrote:
> Thank you for references both.
>
> Actually, I'd like to have PR like #83961. Is it acceptable to merge this
> kind of PR in that case then?
I don't feel the patches are related. I think you can only format the changed
lines.
ChuanqiXu9 wrote:
Oh, I found it here: https://llvm.org/docs/CodingStandards.html#introduction
> Our long term goal is for the entire codebase to follow the convention, but
> we explicitly do not want patches that do large-scale reformatting of
> existing code.
ChuanqiXu9 wrote:
I remember we have policies that we don't like patches which purely formats
codes. It makes backporting and cherry-picking harder. But I can't find the
wording now.
CC: @AaronBallman @Endilll
https://github.com/llvm/llvm-project/pull/83974
https://github.com/ChuanqiXu9 commented:
Thanks. This looks good to me except few nit comments.
Have you tested on a real world workloads?
https://github.com/llvm/llvm-project/pull/79712
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
@@ -167,6 +167,53 @@ class CoroCloner {
} // end anonymous namespace
+// FIXME:
+// Lower the intrinisc in CoroEarly phase if coroutine frame doesn't escape
+// and it is known that other transformations, for example, sanitizers
+// won't lead to incorrect code.
+static void
@@ -338,6 +414,71 @@ static QualType getCoroutineSuspendExprReturnType(const
ASTContext ,
}
#endif
+llvm::Function *
+CodeGenFunction::generateAwaitSuspendWrapper(Twine const ,
+ Twine const ,
+
https://github.com/ChuanqiXu9 edited
https://github.com/llvm/llvm-project/pull/79712
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -72,6 +72,10 @@ sections with improvements to Clang's support for those
languages.
C++ Language Changes
+C++14 Feature Support
+^
+- Sized deallocation is enabled by default in C++14 onwards.
ChuanqiXu9 wrote:
It
@@ -0,0 +1,44 @@
+//===--- SizedDellocation.h - Sized Deallocation *- C++
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier:
ChuanqiXu9 wrote:
@mordante if we want this for 18, we need to land and backport it in this week.
https://github.com/llvm/llvm-project/pull/82160
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
ChuanqiXu9 wrote:
> That'd mean that we "just" need to replace LazySpecializationInfo
> *LazySpecializations = nullptr; with the on-disk hash table approach. That
> would probably require centralizing that logic somewhere in the ASTReader
> (the way this PR does) but with minimal changes wrt
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/83108
>From 59e1880df74434e3c446705788d92b5949d99536 Mon Sep 17 00:00:00 2001
From: Vassil Vassilev
Date: Sun, 7 Jan 2018 15:16:11 +0200
Subject: [PATCH 1/3] D41416: [modules] [pch] Do not deserialize all lazy
ChuanqiXu9 wrote:
Weird. I only see two failures in my local environment:
```
Failed Tests (2):
Clang :: Modules/cxx-templates.cpp
Clang :: Modules/odr_hash.cpp
```
And I saw both of them in my patch. It is simply order mismatches.
https://github.com/llvm/llvm-project/pull/83108
ChuanqiXu9 wrote:
Oh, I didn't notice you've removed D153003 already. But the branch name looks
not good. So I've created a pr in
https://github.com/llvm/llvm-project/pull/83108
https://github.com/llvm/llvm-project/pull/76774
___
cfe-commits mailing
ChuanqiXu9 wrote:
Personally I feel this patch is good and the testing result from our workload
shows it is good too. But it looks like the performance testing results from
google @zygoloid @ilya-biryukov is not good. So maybe we need to wait for
landing this. (It will be great if
https://github.com/ChuanqiXu9 created
https://github.com/llvm/llvm-project/pull/83108
This from https://reviews.llvm.org/D41416. And we plan to introduce on disk
hash table based on this. See https://github.com/llvm/llvm-project/pull/76774.
Following off are cited from
ChuanqiXu9 wrote:
@rjmccall @dwblaikie
https://github.com/llvm/llvm-project/pull/75912
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -41,7 +41,7 @@ void TestCatch2() {
try {
}
// CHECK-NEXT:CXXCatchStmt
-// CHECK-NEXT: NULL
+// CHECK-NEXT: VarDecl {{.*}} ''
ChuanqiXu9 wrote:
Maybe we can improve to print this.
https://github.com/llvm/llvm-project/pull/80976
@@ -1053,6 +1053,10 @@ class VarDecl : public DeclaratorDecl, public
Redeclarable {
LLVM_PREFERRED_TYPE(bool)
unsigned ExceptionVar : 1;
+/// To Check the ellipsis
+LLVM_PREFERRED_TYPE(bool)
+unsigned EllipsisVar : 1;
ChuanqiXu9 wrote:
@@ -16983,7 +16983,7 @@ VarDecl *Sema::BuildExceptionDeclaration(Scope *S,
/// ActOnExceptionDeclarator - Parsed the exception-declarator in a C++ catch
/// handler.
-Decl *Sema::ActOnExceptionDeclarator(Scope *S, Declarator ) {
+Decl *Sema::ActOnExceptionDeclarator(Scope *S,
@@ -1053,6 +1053,10 @@ class VarDecl : public DeclaratorDecl, public
Redeclarable {
LLVM_PREFERRED_TYPE(bool)
unsigned ExceptionVar : 1;
+/// To Check the ellipsis
ChuanqiXu9 wrote:
The comment is not clear
@@ -2698,9 +2698,16 @@ StmtResult Parser::ParseCXXCatchBlock(bool FnCatch) {
Declarator ExDecl(DS, Attributes, DeclaratorContext::CXXCatch);
ParseDeclarator(ExDecl);
ExceptionDecl = Actions.ActOnExceptionDeclarator(getCurScope(), ExDecl);
- } else
-
@@ -271,6 +271,9 @@ void TextNodeDumper::Visit(const Decl *D) {
OS << " hidden";
if (D->isImplicit())
OS << " implicit";
+ if (const VarDecl *ND = dyn_cast(D))
+ if (ND->isEllipsisVariable())
+ OS << " catch_all";
ChuanqiXu9 wrote:
ditto
@@ -115,6 +115,10 @@ void JSONNodeDumper::Visit(const Decl *D) {
else if (D->isThisDeclarationReferenced())
JOS.attribute("isReferenced", true);
+ if (const VarDecl *ND = dyn_cast(D))
+ if (ND->isEllipsisVariable())
+ JOS.attribute("catch_all", true);
@@ -1474,6 +1478,16 @@ class VarDecl : public DeclaratorDecl, public
Redeclarable {
NonParmVarDeclBits.ExceptionVar = EV;
}
+ /// Determine the Ellipsis (...) or not
+ bool isEllipsisVariable() const {
+return isa(this) ? false : NonParmVarDeclBits.EllipsisVar;
+
https://github.com/ChuanqiXu9 commented:
+1 that we should reduce the impact of the patch as much as possible.
Also every time we change the data member of decls and stmts, we need to update
the serialization part.
https://github.com/llvm/llvm-project/pull/80976
https://github.com/ChuanqiXu9 edited
https://github.com/llvm/llvm-project/pull/80976
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ChuanqiXu9 approved this pull request.
https://github.com/llvm/llvm-project/pull/82773
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Chuanqi Xu
Date: 2024-02-23T16:54:13+08:00
New Revision: b014944e47ba6e2031e968268b15fba43a9e1dbf
URL:
https://github.com/llvm/llvm-project/commit/b014944e47ba6e2031e968268b15fba43a9e1dbf
DIFF:
https://github.com/llvm/llvm-project/commit/b014944e47ba6e2031e968268b15fba43a9e1dbf.diff
Author: Chuanqi Xu
Date: 2024-02-23T11:05:15+08:00
New Revision: 2e5af56b05c2d39ab2c829bf4c13190523b67ddd
URL:
https://github.com/llvm/llvm-project/commit/2e5af56b05c2d39ab2c829bf4c13190523b67ddd
DIFF:
https://github.com/llvm/llvm-project/commit/2e5af56b05c2d39ab2c829bf4c13190523b67ddd.diff
ChuanqiXu9 wrote:
> > > > Let's zoom out a little. The approach in D41416 shows that it is
> > > > feasible to store _a_ hash of the template arguments to delay eager
> > > > deserializations. The ODR hash approach is a second order problem
> > > > because we can swap it with something better
Author: Chuanqi Xu
Date: 2024-02-20T14:33:48+08:00
New Revision: 96e56573089b2a211c71660b0ffc7deb21049bdd
URL:
https://github.com/llvm/llvm-project/commit/96e56573089b2a211c71660b0ffc7deb21049bdd
DIFF:
https://github.com/llvm/llvm-project/commit/96e56573089b2a211c71660b0ffc7deb21049bdd.diff
ChuanqiXu9 wrote:
I'd like to close this since the issue got closed.
https://github.com/llvm/llvm-project/pull/81919
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ChuanqiXu9 closed
https://github.com/llvm/llvm-project/pull/81919
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ChuanqiXu9 closed
https://github.com/llvm/llvm-project/pull/82302
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
ChuanqiXu9 wrote:
The CI failure looks unrelated to this:
```
CMake Error at
C:/BuildTools/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.20/Modules/CMakeDetermineCompilerId.cmake:777
(file):
--
| file STRINGS file
|
https://github.com/ChuanqiXu9 closed
https://github.com/llvm/llvm-project/pull/80687
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/80687
>From 19065e2e25e8bbd735b157239702e4394659bbc7 Mon Sep 17 00:00:00 2001
From: Chuanqi Xu
Date: Mon, 5 Feb 2024 22:31:19 +0800
Subject: [PATCH 1/2] [docs] [C++20] [Modules] Ideas for transiting to modules
---
https://github.com/ChuanqiXu9 created
https://github.com/llvm/llvm-project/pull/82302
Close https://github.com/llvm/llvm-project/issues/80570.
In
https://github.com/llvm/llvm-project/commit/a0b6747804e46665ecfd00295b60432bfe1775b6,
we skipped ODR checks for decls in GMF. Then it should be
https://github.com/ChuanqiXu9 approved this pull request.
LGTM.
https://github.com/llvm/llvm-project/pull/82179
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
ChuanqiXu9 wrote:
> Let's zoom out a little. The approach in D41416 shows that it is feasible to
> store _a_ hash of the template arguments to delay eager deserializations. The
> ODR hash approach is a second order problem because we can swap it with
> something better once we need to. In
@@ -0,0 +1,38 @@
+// Test that -print-library-module-manifest-path finds the correct file.
+
+// REQUIRES: x86-registered-target
ChuanqiXu9 wrote:
```suggestion
// FIXME:
// REQUIRES: x86-registered-target
```
I feel better with a FIXME to remind us to
https://github.com/ChuanqiXu9 approved this pull request.
LGTM.
https://github.com/llvm/llvm-project/pull/82160
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ChuanqiXu9 edited
https://github.com/llvm/llvm-project/pull/82160
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
ChuanqiXu9 wrote:
> > But my point is that we can't land that if we don't understand what's going
> > wrong without that patch.
>
> We understand that very well and it's described in
> https://reviews.llvm.org/D153003 as well as the surrounding discussions:
> because of the way that
ChuanqiXu9 wrote:
> > > > > > > > > > [do not merge] [runtime-cxxmodules] Rework our lazy
> > > > > > > > > > template specialization deserialization mechanism
> > > > > > > > > > [root-project/root#14495](https://github.com/root-project/root/pull/14495)
> > > > > > > > >
> > > > > > > > >
>
ChuanqiXu9 wrote:
> > > > > > > > [do not merge] [runtime-cxxmodules] Rework our lazy template
> > > > > > > > specialization deserialization mechanism
> > > > > > > > [root-project/root#14495](https://github.com/root-project/root/pull/14495)
> > > > > > >
> > > > > > >
> > > > > > > From
>
ChuanqiXu9 wrote:
> > > > > > > > > [do not merge] [runtime-cxxmodules] Rework our lazy template
> > > > > > > > > specialization deserialization mechanism
> > > > > > > > > [root-project/root#14495](https://github.com/root-project/root/pull/14495)
> > > > > > > >
> > > > > > > >
> > > > > >
ChuanqiXu9 wrote:
> > > > > > > [do not merge] [runtime-cxxmodules] Rework our lazy template
> > > > > > > specialization deserialization mechanism
> > > > > > > [root-project/root#14495](https://github.com/root-project/root/pull/14495)
> > > > > >
> > > > > >
> > > > > > From
> > > > > >
https://github.com/ChuanqiXu9 commented:
Sounds good. My instinct reaction to the title is that you're going to unify
the annoying duplicated interfaces for the 5 specialization classes (function
specialization, class/var (partial) specializations). But it is still good to
merge these
@@ -1792,23 +1807,11 @@ class ClassTemplateSpecializationDecl
llvm::PointerUnion
SpecializedTemplate;
- /// Further info for explicit template specialization/instantiation.
- struct ExplicitSpecializationInfo {
-/// The type-as-written.
-TypeSourceInfo
https://github.com/ChuanqiXu9 edited
https://github.com/llvm/llvm-project/pull/81642
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
ChuanqiXu9 wrote:
> > > > > [do not merge] [runtime-cxxmodules] Rework our lazy template
> > > > > specialization deserialization mechanism
> > > > > [root-project/root#14495](https://github.com/root-project/root/pull/14495)
> > > >
> > > >
> > > > From
> > > >
Author: Chuanqi Xu
Date: 2024-02-18T15:15:28+08:00
New Revision: 1ecbab56dcbb78268c8d19af34a50591f90b12a0
URL:
https://github.com/llvm/llvm-project/commit/1ecbab56dcbb78268c8d19af34a50591f90b12a0
DIFF:
https://github.com/llvm/llvm-project/commit/1ecbab56dcbb78268c8d19af34a50591f90b12a0.diff
ChuanqiXu9 wrote:
> > > [do not merge] [runtime-cxxmodules] Rework our lazy template
> > > specialization deserialization mechanism
> > > [root-project/root#14495](https://github.com/root-project/root/pull/14495)
> >
> >
> > From
> >
ChuanqiXu9 wrote:
> [do not merge] [runtime-cxxmodules] Rework our lazy template specialization
> deserialization mechanism root-project/root#14495
>From https://github.com/root-project/root/pull/14495, I see there is new reply
>saying the testing is actually fine. Do you think we still need
ChuanqiXu9 wrote:
@iains @mizvekov ping~
https://github.com/llvm/llvm-project/pull/75894
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
ChuanqiXu9 wrote:
(This is another example that the github review can't work well with the
reverted patches...)
@mordante I think you can add `// REQUIRES: x86-registered-target` to the test
if @kaz7 can't respond quickly. It will skip the test on targets other than
x86. And it should keep
@@ -5097,6 +5099,22 @@ class CoroutineSuspendExpr : public Expr {
return static_cast(SubExprs[SubExpr::Operand]);
}
+ SuspendReturnType getSuspendReturnType() const {
+auto *SuspendExpr = getSuspendExpr();
+assert(SuspendExpr);
+
+auto SuspendType =
@@ -232,16 +250,74 @@ static LValueOrRValue
emitSuspendExpression(CodeGenFunction , CGCoroData
auto *NullPtr = llvm::ConstantPointerNull::get(CGF.CGM.Int8PtrTy);
auto *SaveCall = Builder.CreateCall(CoroSave, {NullPtr});
+ const auto AwaitSuspendCanThrow =
+
@@ -1396,9 +1478,18 @@ static bool simplifySuspendPoint(CoroSuspendInst
*Suspend,
if (!SubFn)
return false;
- // Does not refer to the current coroutine, we cannot do anything with it.
- if (SubFn->getFrame() != CoroBegin)
-return false;
+ auto Frame =
@@ -5038,6 +5038,8 @@ class CoroutineSuspendExpr : public Expr {
OpaqueValueExpr *OpaqueValue = nullptr;
public:
+ enum SuspendReturnType { SuspendVoid, SuspendBool, SuspendHandle };
ChuanqiXu9 wrote:
nit: Add a comment to explain that the return type of
https://github.com/ChuanqiXu9 commented:
Thanks. This looks much better now.
Given the CoroAwaitSuspendInst is lowered before splitting coroutines, I think
we don't need to handle it specially in `CoroSplit` any more.
https://github.com/llvm/llvm-project/pull/79712
@@ -2013,6 +2104,10 @@ splitCoroutine(Function , SmallVectorImpl
,
buildCoroutineFrame(F, Shape, MaterializableCallback);
replaceFrameSizeAndAlignment(Shape);
+ IRBuilder<> Builder(M.getContext());
ChuanqiXu9 wrote:
```suggestion
IRBuilder<>
@@ -380,66 +380,7 @@ static Expr *maybeTailCall(Sema , QualType RetType, Expr
*E,
// __builtin_coro_resume so that the cleanup code are not inserted in-between
// the resume call and return instruction, which would interfere with the
// musttail call contract.
-
@@ -167,6 +167,47 @@ class CoroCloner {
} // end anonymous namespace
+// FIXME:
+// Lower the intrinisc earlier if coroutine frame doesn't escape
ChuanqiXu9 wrote:
```suggestion
// Lower the intrinisc in CoroEarly phase if coroutine frame doesn't escape
```
@@ -232,16 +250,74 @@ static LValueOrRValue
emitSuspendExpression(CodeGenFunction , CGCoroData
auto *NullPtr = llvm::ConstantPointerNull::get(CGF.CGM.Int8PtrTy);
auto *SaveCall = Builder.CreateCall(CoroSave, {NullPtr});
+ const auto AwaitSuspendCanThrow =
+
@@ -338,6 +414,71 @@ static QualType getCoroutineSuspendExprReturnType(const
ASTContext ,
}
#endif
+llvm::Function *
+CodeGenFunction::generateAwaitSuspendWrapper(Twine const ,
+ Twine const ,
+
@@ -232,16 +250,74 @@ static LValueOrRValue
emitSuspendExpression(CodeGenFunction , CGCoroData
auto *NullPtr = llvm::ConstantPointerNull::get(CGF.CGM.Int8PtrTy);
auto *SaveCall = Builder.CreateCall(CoroSave, {NullPtr});
+ const auto AwaitSuspendCanThrow =
+
@@ -173,19 +173,36 @@ static bool ResumeStmtCanThrow(const Stmt *S) {
return false;
}
+static bool AwaitSuspendStmtCanThrow(const Stmt *S) {
+ return ResumeStmtCanThrow(S);
+}
+
// Emit suspend expression which roughly looks like:
//
// auto && x = CommonExpr();
//
https://github.com/ChuanqiXu9 edited
https://github.com/llvm/llvm-project/pull/79712
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
301 - 400 of 1270 matches
Mail list logo
