Author: Chuanqi Xu
Date: 2024-04-02T09:58:59+08:00
New Revision: 21f85e230056172cffcaec76352e5a2019b54b86
URL:
https://github.com/llvm/llvm-project/commit/21f85e230056172cffcaec76352e5a2019b54b86
DIFF:
https://github.com/llvm/llvm-project/commit/21f85e230056172cffcaec76352e5a2019b54b86.diff
LO
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/85050
>From 79706501a7a3f0f2e0e9c9411bdd5e00e34ae175 Mon Sep 17 00:00:00 2001
From: Chuanqi Xu
Date: Tue, 12 Mar 2024 17:26:49 +0800
Subject: [PATCH 1/3] [C++20] [Modules] Introduce -fgen-reduced-bmi
---
clang/inc
@@ -193,6 +193,20 @@ DwarfFissionKind getDebugFissionKind(const Driver &D,
const llvm::opt::ArgList &Args,
llvm::opt::Arg *&Arg);
+// Calculate the output path of the module file when compiling a module
@@ -3017,6 +3017,7 @@ defm prebuilt_implicit_modules :
BoolFOption<"prebuilt-implicit-modules",
def fmodule_output_EQ : Joined<["-"], "fmodule-output=">,
Flags<[NoXarchOption]>, Visibility<[ClangOption, CC1Option]>,
+ MarshallingInfoString>,
ChuanqiXu9 wro
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/75912
>From 7399d2417a4b758fa0a98da1f99f3b4ec0eb1046 Mon Sep 17 00:00:00 2001
From: Chuanqi Xu
Date: Tue, 19 Dec 2023 17:00:59 +0800
Subject: [PATCH 1/3] [C++20] [Modules] [Itanium ABI] Generate the vtable in
the m
@@ -1483,10 +1483,15 @@ void ASTDeclWriter::VisitCXXRecordDecl(CXXRecordDecl
*D) {
if (D->isThisDeclarationADefinition())
Record.AddCXXDefinitionData(D);
- // Store (what we currently believe to be) the key function to avoid
- // deserializing every method so we can c
@@ -41,9 +43,10 @@ Base::~Base() {}
// CHECK: @_ZTSW3Mod4Base = constant
// CHECK: @_ZTIW3Mod4Base = constant
-// CHECK-INLINE: @_ZTVW3Mod4Base = linkonce_odr {{.*}}unnamed_addr constant
-// CHECK-INLINE: @_ZTSW3Mod4Base = linkonce_odr {{.*}}constant
-// CHECK-INLINE: @_ZTIW3M
ChuanqiXu9 wrote:
Hi Andreas, thanks for looking into this. I am still confused about whether or
not your new branch can fix the crash or not.
For the question about the crash itself, I don't have any insight though, I
feel like this is a defect in the code generator. I didn't understand why m
@@ -610,6 +610,345 @@ the following style significantly:
The key part of the tip is to reduce the duplications from the text includes.
+Ideas for converting to modules
+---
+
+For new libraries, we encourage them to use modules completely from day
ChuanqiXu9 wrote:
I feel whether the param is needed is not related whether the allocation
happens.
The param isn't needed means it is not used.
https://github.com/llvm/llvm-project/pull/81195
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
ChuanqiXu9 wrote:
yes if I remember correctly. I am away from the computer so I can't find the
wording.
But I don't think this is related to how the frame gets allocated.
https://github.com/llvm/llvm-project/pull/81195
___
cfe-commits mailing list
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.
https://github.com/ll
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
LO
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
_
@@ -6898,10 +6898,18 @@ class Sema final {
BinaryOperatorKind Operator);
ActOnCXXThis - Parse 'this' pointer.
- ExprResult ActOnCXXThis(SourceLocation loc);
+ ///
+ /// \param SkipLambdaCaptureCheck Whether to skip the 'this' check
@@ -6898,10 +6898,18 @@ class Sema final {
BinaryOperatorKind Operator);
ActOnCXXThis - Parse 'this' pointer.
- ExprResult ActOnCXXThis(SourceLocation loc);
+ ///
+ /// \param SkipLambdaCaptureCheck Whether to skip the 'this' check
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
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-com
@@ -6898,10 +6898,18 @@ class Sema final {
BinaryOperatorKind Operator);
ActOnCXXThis - Parse 'this' pointer.
- ExprResult ActOnCXXThis(SourceLocation loc);
+ ///
+ /// \param SkipLambdaCaptureCheck Whether to skip the 'this' check
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 its
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 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 po
@@ -744,6 +744,9 @@ getCompilationDataBase(int argc, char **argv, std::string
&ErrorMessage) {
return nullptr;
}
+ // Only 1 threads is required if P1689 per file mode.
+ NumThreads = 1;
ChuanqiXu9 wrote:
Makes sense. Done.
https://github.com/llvm/l
@@ -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 " << Inp
@@ -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 " << Inp
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 po
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 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
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 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
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
LO
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
(https://github.com/alibaba/a
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
LO
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
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 happen
@@ -744,6 +744,9 @@ getCompilationDataBase(int argc, char **argv, std::string
&ErrorMessage) {
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 som
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 po
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 po
@@ -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 " << Inp
https://github.com/ChuanqiXu9 created
https://github.com/llvm/llvm-project/pull/84881
Following of https://github.com/llvm/llvm-project/pull/82160
The reason why the above PR fails is that the `--sysroot` has lower priority
than the libc++ built from the same source. On the one hand, it matche
ChuanqiXu9 wrote:
I sent the new PR in https://github.com/llvm/llvm-project/pull/84881. See the
comments there for details.
https://github.com/llvm/llvm-project/pull/82160
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/
https://github.com/ChuanqiXu9 closed
https://github.com/llvm/llvm-project/pull/84285
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Chuanqi Xu
Date: 2024-03-13T11:22:32+08:00
New Revision: 5d7796e674224be54c48a8db981f4134845bcc7c
URL:
https://github.com/llvm/llvm-project/commit/5d7796e674224be54c48a8db981f4134845bcc7c
DIFF:
https://github.com/llvm/llvm-project/commit/5d7796e674224be54c48a8db981f4134845bcc7c.diff
LO
Author: Chuanqi Xu
Date: 2024-03-13T13:57:52+08:00
New Revision: 4d62929852849f768d7397f634cfdebc85de96a4
URL:
https://github.com/llvm/llvm-project/commit/4d62929852849f768d7397f634cfdebc85de96a4
DIFF:
https://github.com/llvm/llvm-project/commit/4d62929852849f768d7397f634cfdebc85de96a4.diff
LO
https://github.com/ChuanqiXu9 created
https://github.com/llvm/llvm-project/pull/85050
This is the driver part of https://github.com/llvm/llvm-project/pull/75894.
This patch introduces '-fgen-reduced-bmi' to enable generating the reduced BMI.
This patch did:
- When `-fgen-reduced-bmi` is specif
https://github.com/ChuanqiXu9 converted_to_draft
https://github.com/llvm/llvm-project/pull/85050
___
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/85050
>From e5114cdc6a77711dda6a13cbee9cd5cc42be48c6 Mon Sep 17 00:00:00 2001
From: Chuanqi Xu
Date: Tue, 12 Mar 2024 17:26:49 +0800
Subject: [PATCH] [C++20] [Modules] Introduce -fgen-reduced-bmi
---
clang/include
https://github.com/ChuanqiXu9 ready_for_review
https://github.com/llvm/llvm-project/pull/85050
___
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
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 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
__
@@ -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;
+
@@ -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);
@@ -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
https://github.com/llvm/llvm-project/p
@@ -2698,9 +2698,16 @@ StmtResult Parser::ParseCXXCatchBlock(bool FnCatch) {
Declarator ExDecl(DS, Attributes, DeclaratorContext::CXXCatch);
ParseDeclarator(ExDecl);
ExceptionDecl = Actions.ActOnExceptionDeclarator(getCurScope(), ExDecl);
- } else
-ConsumeToken
@@ -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 &D) {
+Decl *Sema::ActOnExceptionDeclarator(Scope *S
@@ -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
https:
@@ -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:
Sh
@@ -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
___
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
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 https://reviews.llvm.org
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 @ilya-biryuk
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:
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
__
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
temp
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 D
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
https://lists.llvm.org/cgi-bin/mailman/listinfo/cf
@@ -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: Apa
@@ -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 m
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
@@ -338,6 +414,71 @@ static QualType getCoroutineSuspendExprReturnType(const
ASTContext &Ctx,
}
#endif
+llvm::Function *
+CodeGenFunction::generateAwaitSuspendWrapper(Twine const &CoroName,
+ Twine const &SuspendPointName,
+
@@ -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
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
https://
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
__
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.
https://github.com/llvm/llvm-pr
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.
https://github.com/llvm/llvm-project/pull/8397
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 t
@@ -830,6 +843,19 @@ class PCHGenerator : public SemaConsumer {
bool hasEmittedPCH() const { return Buffer->IsComplete; }
};
+class ReducedBMIGenerator : public PCHGenerator {
+public:
+ ReducedBMIGenerator(const Preprocessor &PP, InMemoryModuleCache &ModuleCache,
+
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
__
ChuanqiXu9 wrote:
> with stack exhaustion warning, the compiler can continue (albeit being slow
> or unstable). The depth limit here will be a hard restriction and so there
> will be no workaround if the code reaches it.
It is a surprise to me that this is only a warning instead of a hard erro
https://github.com/ChuanqiXu9 approved this pull request.
LGTM then.
https://github.com/llvm/llvm-project/pull/75545
___
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/75545
___
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/79261
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/ChuanqiXu9 commented:
This is what I had in mind
https://github.com/llvm/llvm-project/pull/79261
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,31 @@
+// UNSUPPORTED: system-aix
+//
+// RUN: rm -rf %t
+// RUN: mkdir -p %t
+// RUN: split-file %s %t
+//
+// RUN: %clang -std=c++20 %t/mod.cppm --precompile \
+// RUN: -o %t/mod.pcm
+// RUN: %clang %t/mod.pcm -c -o %t/mod.o
+// RUN: %clang -shared %t/mod.o -o %t/
@@ -0,0 +1,31 @@
+// UNSUPPORTED: system-aix
+//
+// RUN: rm -rf %t
+// RUN: mkdir -p %t
+// RUN: split-file %s %t
+//
+// RUN: %clang -std=c++20 %t/mod.cppm --precompile \
+// RUN: -o %t/mod.pcm
+// RUN: %clang %t/mod.pcm -c -o %t/mod.o
+// RUN: %clang -shared %t/mod.o -o %t/
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/79959
>From beb1a4b89f941f41a6e220447dcda6d6fc231a0b Mon Sep 17 00:00:00 2001
From: Chuanqi Xu
Date: Tue, 30 Jan 2024 15:57:35 +0800
Subject: [PATCH 1/2] [C++20] [Modules] Introduce -fskip-odr-check-in-gmf
Close ht
@@ -457,6 +457,28 @@ Note that **currently** the compiler doesn't consider
inconsistent macro definit
Currently Clang would accept the above example. But it may produce surprising
results if the
debugging code depends on consistent use of ``NDEBUG`` also in other
translation
@@ -457,6 +457,28 @@ Note that **currently** the compiler doesn't consider
inconsistent macro definit
Currently Clang would accept the above example. But it may produce surprising
results if the
debugging code depends on consistent use of ``NDEBUG`` also in other
translation
ChuanqiXu9 wrote:
> I'd still idly vote against adding this flag/support - but if other modules
> contributors feel it's the right thing to do, I won't stand in the way.
Yeah, as @mizvekov said, this is intended to be a transparent change to users.
(unless the users are testing volunteers, whi
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
https://github.com/ChuanqiXu9 commented:
I got the reason why I felt `__await_suspend_helper_` was odd. In my
imagination, we only need to emit the function `await_suspend(handle)` to an
LLVM function and pass that to `llvm.coro.await.suspend` directly.
https://github.com/llvm/llvm-project/pul
@@ -173,6 +173,10 @@ static bool ResumeStmtCanThrow(const Stmt *S) {
return false;
}
+static bool AwaitSuspendStmtCanThrow(const Stmt *S) {
+ return ResumeStmtCanThrow(S);
+}
ChuanqiXu9 wrote:
Maybe it will be better to rename `ResumeStmtCanThrow` to `Stmt
@@ -232,16 +237,59 @@ static LValueOrRValue
emitSuspendExpression(CodeGenFunction &CGF, CGCoroData &Co
auto *NullPtr = llvm::ConstantPointerNull::get(CGF.CGM.Int8PtrTy);
auto *SaveCall = Builder.CreateCall(CoroSave, {NullPtr});
- CGF.CurCoro.InSuspendBlock = true;
- aut
@@ -5036,14 +5036,17 @@ class CoroutineSuspendExpr : public Expr {
Stmt *SubExprs[SubExpr::Count];
OpaqueValueExpr *OpaqueValue = nullptr;
+ OpaqueValueExpr *OpaqueFramePtr = nullptr;
ChuanqiXu9 wrote:
I still think we can get rid of storing `OpaqueFrame
@@ -79,6 +79,73 @@ using namespace llvm;
namespace {
+// Created on demand if the coro-early pass has work to do.
+class Lowerer : public coro::LowererBase {
+ IRBuilder<> Builder;
+ void lowerAwaitSuspend(CoroAwaitSuspendInst *CB);
+
+public:
+ Lowerer(Module &M) : Lowere
@@ -1744,6 +1744,273 @@ a call to ``llvm.coro.suspend.retcon`` after resuming
abnormally.
In a yield-once coroutine, it is undefined behavior if the coroutine
executes a call to ``llvm.coro.suspend.retcon`` after resuming in any way.
+.. _coro.await.suspend:
+
+'llvm.coro.awa
@@ -232,16 +237,59 @@ static LValueOrRValue
emitSuspendExpression(CodeGenFunction &CGF, CGCoroData &Co
auto *NullPtr = llvm::ConstantPointerNull::get(CGF.CGM.Int8PtrTy);
auto *SaveCall = Builder.CreateCall(CoroSave, {NullPtr});
- CGF.CurCoro.InSuspendBlock = true;
- aut
@@ -1744,6 +1744,273 @@ a call to ``llvm.coro.suspend.retcon`` after resuming
abnormally.
In a yield-once coroutine, it is undefined behavior if the coroutine
executes a call to ``llvm.coro.suspend.retcon`` after resuming in any way.
+.. _coro.await.suspend:
+
+'llvm.coro.awa
@@ -1744,6 +1744,273 @@ a call to ``llvm.coro.suspend.retcon`` after resuming
abnormally.
In a yield-once coroutine, it is undefined behavior if the coroutine
executes a call to ``llvm.coro.suspend.retcon`` after resuming in any way.
+.. _coro.await.suspend:
+
+'llvm.coro.awa
@@ -232,16 +237,59 @@ static LValueOrRValue
emitSuspendExpression(CodeGenFunction &CGF, CGCoroData &Co
auto *NullPtr = llvm::ConstantPointerNull::get(CGF.CGM.Int8PtrTy);
auto *SaveCall = Builder.CreateCall(CoroSave, {NullPtr});
- CGF.CurCoro.InSuspendBlock = true;
- aut
401 - 500 of 1813 matches
Mail list logo
