ChuanqiXu9 wrote:
This is a simple fix to a problem with a (relatively) long history. I think it
is good to backport this.
https://github.com/llvm/llvm-project/pull/133198
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https:/
@@ -67,35 +68,84 @@ Semantic Highlighting
Compile flags
^
+- Fixed a bug where clangd would unnecessarily reparse open files whose
+ compile command did not change when receiving a new compile command
+ via an LSP `workspace/configuration` request (#GH115438)
+
ChuanqiXu9 wrote:
> @ChuanqiXu9 What do you think about merging this PR to the release branch?
It is necessary for using std module on MacOS with CMake. I think it is
important.
https://github.com/llvm/llvm-project/pull/122844
___
llvm-branch-commits
ChuanqiXu9 wrote:
CC @jijjijj
https://github.com/llvm/llvm-project/pull/121739
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/ChuanqiXu9 approved this pull request.
The change itself looks good to me.
https://github.com/llvm/llvm-project/pull/121739
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailma
ChuanqiXu9 wrote:
@jijjijj Please note the commits in the summary
https://github.com/llvm/llvm-project/pull/121739
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commi
https://github.com/ChuanqiXu9 milestoned
https://github.com/llvm/llvm-project/pull/121739
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
ChuanqiXu9 wrote:
The tests are failing and it looks relevent.
https://github.com/llvm/llvm-project/pull/121046
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
ChuanqiXu9 wrote:
Sent https://github.com/llvm/llvm-project/pull/119333
It looks like the lldb's failure is from we forgot to update the
ExternalASTConsumer (I met this the second time. I am wondering if we can make
it more automatically). The other windows failure is a pattern match failure.
https://github.com/ChuanqiXu9 closed
https://github.com/llvm/llvm-project/pull/83233
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
ChuanqiXu9 wrote:
Sent
https://github.com/llvm/llvm-project/commit/b5bd1928c6d43bc525a4e3fb65d2c750d61e
and see https://github.com/llvm/llvm-project/pull/83237#issuecomment-2521945547
https://github.com/llvm/llvm-project/pull/83233
___
llvm-branc
ChuanqiXu9 wrote:
Sent
https://github.com/llvm/llvm-project/commit/b5bd1928c6d43bc525a4e3fb65d2c750d61e
https://github.com/llvm/llvm-project/pull/83237
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/
https://github.com/ChuanqiXu9 closed
https://github.com/llvm/llvm-project/pull/83237
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
ChuanqiXu9 wrote:
Note that I'll merge this and https://github.com/llvm/llvm-project/pull/83233
and https://github.com/llvm/llvm-project/pull/83108 into a commit and commit it
directly to trunk. Since these prs are split initially to make it clear to be
reviewed. But during the review, we alwa
ChuanqiXu9 wrote:
> Once again, thanks for bearing with us and addressing all the issues. The
> latest version seems both correct and does not cause performance regressions.
> Let's land this!
>
> PS please note that the resolution of our compile-time profiling instruments
> is not that great
ChuanqiXu9 wrote:
@alexfh gentle ping
https://github.com/llvm/llvm-project/pull/83237
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
ChuanqiXu9 wrote:
> @ChuanqiXu9 is this one ready to be merged?
Yes, I believe this is ready to be merged.
https://github.com/llvm/llvm-project/pull/114197
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/
ChuanqiXu9 wrote:
@vgvassilev @ilya-biryukov @alexfh If I read correctly, the only blocker issue
is the above reported performance issue. And I tried to split partial
specialization from the full specialization table to avoid merging tables again
and again. Could you please take another round
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/83237
>From 493cb7cdafeb22efa9e9f3c1954b6de1e2665365 Mon Sep 17 00:00:00 2001
From: Chuanqi Xu
Date: Wed, 28 Feb 2024 11:41:53 +0800
Subject: [PATCH 1/2] [Serialization] Code cleanups and polish 83233
---
clang/in
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/83233
>From 11726437efb760c9f2aba9b2258337b2b8eb4bb6 Mon Sep 17 00:00:00 2001
From: Chuanqi Xu
Date: Fri, 8 Nov 2024 17:19:33 +0800
Subject: [PATCH] [Serialization] Introduce OnDiskHashTable for specializations
---
ChuanqiXu9 wrote:
Sorry for the not good stacked PR operation.
https://github.com/llvm/llvm-project/pull/83237
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/83233
>From f565dd3f156bbdf608be6643208c40f02b4f0e83 Mon Sep 17 00:00:00 2001
From: Chuanqi Xu
Date: Wed, 28 Feb 2024 11:41:53 +0800
Subject: [PATCH] [Serialization] Introduce OnDiskHashTable for specializations
Fo
ChuanqiXu9 wrote:
> > I tried to take a look at eigen and it looks like the declaration looks
> > well and I had no clue how that happens. A reproducer may be necessary here
> > to proceed. Thanks in advance.
>
> I can reproduce using the following sources and invocations outlined in
> `run.s
ChuanqiXu9 wrote:
> > I tried to take a look at eigen and it looks like the declaration looks
> > well and I had no clue how that happens. A reproducer may be necessary here
> > to proceed. Thanks in advance.
>
> I can reproduce using the following sources and invocations outlined in
> `run.s
ChuanqiXu9 wrote:
> > > do we store all template variable specializations in the same place in
> > > the map including the partial ones?
> >
> >
> > Yes, we identify if they are partial by an additional bit.
> > For the solution, given there might be other places need to load the
> > speciali
ChuanqiXu9 wrote:
> do we store all template variable specializations in the same place in the
> map including the partial ones?
Yes, we identify if they are partial by an additional bit.
For the solution, given there might be other places need to load the
specializations, how about removing
ChuanqiXu9 wrote:
@alexfh thank you very much!
@vgvassilev but we have to provide similar mechanism, so it is allowed to get
all the specializations for a templated decl.
https://github.com/llvm/llvm-project/pull/83237
___
llvm-branch-commits mailing
ChuanqiXu9 wrote:
> @usx95 may be able to help with the reproducer.
>
> In the meantime, I'm trying to collect some information on the compile times.
> So far it looks like we have a ~10-15x compile time regression on some
> translation units. Without this patch `-ftime-report` shows:
>
> ```
ChuanqiXu9 wrote:
I tried to take a look at eigen and it looks like the declaration looks well
and I had no clue how that happens. A reproducer may be necessary here to
proceed. Thanks in advance.
https://github.com/llvm/llvm-project/pull/83237
___
l
ChuanqiXu9 wrote:
> We've hit only one correctness issue that we don't yet have a reproducer for,
> but it gives this error:
>
> ```shell
> Eigen/.../plugins/CommonCwiseBinaryOps.inc:47:29: error: inline function
> 'Eigen::operator*' is not defined [-Werror,-Wundefined-inline]
> ```
>
> I'll
ChuanqiXu9 wrote:
> There were some merge conflicts with main, I've managed to resolve them to
> this: https://github.com/ilya-biryukov/llvm-project/tree/pr83237_merged
>
> I am now trying to bootstrap the compiler with that version, but it would be
> useful if someone rebased this PR against
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/83237
>From 5df9f526236cff3b2212088bf6bf52c6802044e2 Mon Sep 17 00:00:00 2001
From: Chuanqi Xu
Date: Wed, 28 Feb 2024 11:41:53 +0800
Subject: [PATCH] [Serialization] Code cleanups and polish 83233
fmt
load special
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/83233
>From b61bcaafa3700b0797772df58710158eb44eaa69 Mon Sep 17 00:00:00 2001
From: Chuanqi Xu
Date: Wed, 28 Feb 2024 11:41:53 +0800
Subject: [PATCH] [Serialization] Introduce OnDiskHashTable for specializations
Fo
ChuanqiXu9 wrote:
@ilya-biryukov gentle ping~
https://github.com/llvm/llvm-project/pull/83237
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
Author: Chuanqi Xu
Date: 2024-09-24T15:41:11+08:00
New Revision: 4c51d827e58aaa8c5b3d75b3b61a43627ab53491
URL:
https://github.com/llvm/llvm-project/commit/4c51d827e58aaa8c5b3d75b3b61a43627ab53491
DIFF:
https://github.com/llvm/llvm-project/commit/4c51d827e58aaa8c5b3d75b3b61a43627ab53491.diff
LO
ChuanqiXu9 wrote:
@ilya-biryukov thanks for the high quality reproducer! I've reproduced it and
fixed it in the newest commit.
The root cause of the failure is the same with the last time: merging
specializations with the same key. The previous fix is not clear since, I just
found, the underl
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/83237
>From f2e53e44eebab4720a1dbade24fcb14d698fb03f Mon Sep 17 00:00:00 2001
From: Chuanqi Xu
Date: Wed, 28 Feb 2024 11:41:53 +0800
Subject: [PATCH 1/7] [Serialization] Code cleanups and polish 83233
---
clang/in
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/109762
>From 4c51d827e58aaa8c5b3d75b3b61a43627ab53491 Mon Sep 17 00:00:00 2001
From: Chuanqi Xu
Date: Tue, 24 Sep 2024 15:37:02 +0800
Subject: [PATCH] [C++20] [Modules] Add Decl::isFromGlobalModule
---
clang/inclu
ChuanqiXu9 wrote:
Oh, maybe some implicit conflicts. I'll add one manually
https://github.com/llvm/llvm-project/pull/109077
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bra
ChuanqiXu9 wrote:
> If you can put up another patch I'll just wait with reverting.
trying : )
https://github.com/llvm/llvm-project/pull/109077
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailm
https://github.com/ChuanqiXu9 approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/109076
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
ChuanqiXu9 wrote:
> @ChuanqiXu9 this looks safe enough to be picked. Does the PR look fine to you?
Yes, I'll try to approve it formally.
https://github.com/llvm/llvm-project/pull/109076
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.ll
https://github.com/ChuanqiXu9 approved this pull request.
https://github.com/llvm/llvm-project/pull/109077
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
ChuanqiXu9 wrote:
> > what the code does is: when we write a on-disk hash table, try to write the
> > imported merged hash table in the same process so that we don't need to
> > read these tables again. However, in line 329 the function will try to omit
> > the data from imported table with th
ChuanqiXu9 wrote:
> > what the code does is: when we write a on-disk hash table, try to write the
> > imported merged hash table in the same process so that we don't need to
> > read these tables again. However, in line 329 the function will try to omit
> > the data from imported table with th
ChuanqiXu9 wrote:
Very sorry that I failed to count
https://github.com/llvm/llvm-project/issues/102933 as a regression support
initially. I thought it was other problems. My bad. And back to the issue
itself, it shows that the fix is pretty simple and it is majorly an oversight
in the develop
https://github.com/ChuanqiXu9 approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/99285
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/ChuanqiXu9 approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/99283
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -0,0 +1,147 @@
+//===- CoroAnnotationElide.cpp - Elide attributed safe coroutine calls
===//
+//
+// 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: Ap
https://github.com/ChuanqiXu9 edited
https://github.com/llvm/llvm-project/pull/99285
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -0,0 +1,147 @@
+//===- CoroAnnotationElide.cpp - Elide attributed safe coroutine calls
===//
+//
+// 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: Ap
@@ -0,0 +1,147 @@
+//===- CoroAnnotationElide.cpp - Elide attributed safe coroutine calls
===//
+//
+// 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: Ap
@@ -0,0 +1,147 @@
+//===- CoroAnnotationElide.cpp - Elide attributed safe coroutine calls
===//
+//
+// 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: Ap
@@ -0,0 +1,147 @@
+//===- CoroAnnotationElide.cpp - Elide attributed safe coroutine calls
===//
+//
+// 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: Ap
@@ -1455,6 +1462,74 @@ struct SwitchCoroutineSplitter {
setCoroInfo(F, Shape, Clones);
}
+ // Create a variant of ramp function that does not perform heap allocation
+ // for a switch ABI coroutine.
+ //
+ // The newly split `.noalloc` ramp function has the following
@@ -1455,6 +1462,74 @@ struct SwitchCoroutineSplitter {
setCoroInfo(F, Shape, Clones);
}
+ // Create a variant of ramp function that does not perform heap allocation
+ // for a switch ABI coroutine.
+ //
+ // The newly split `.noalloc` ramp function has the following
@@ -26,6 +26,10 @@ bool declaresIntrinsics(const Module &M,
const std::initializer_list);
void replaceCoroFree(CoroIdInst *CoroId, bool Elide);
+void suppressCoroAllocs(CoroIdInst *CoroId);
ChuanqiXu9 wrote:
Let's add some comments for
@@ -2049,6 +2055,21 @@ the coroutine must reach the final suspend point when it
get destroyed.
This attribute only works for switched-resume coroutines now.
+coro_elide_safe
+---
+
+When a Call or Invoke instruction is marked with `coro_elide_safe`,
+CoroAnnotati
https://github.com/ChuanqiXu9 commented:
The patch looks good to me except the thing I mentioned in
https://github.com/llvm/llvm-project/pull/99282#pullrequestreview-2265588601
https://github.com/llvm/llvm-project/pull/99283
___
llvm-branch-commits ma
https://github.com/ChuanqiXu9 edited
https://github.com/llvm/llvm-project/pull/99283
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -1827,6 +1833,12 @@ void ASTDeclWriter::VisitVarTemplateDecl(VarTemplateDecl
*D) {
void ASTDeclWriter::VisitVarTemplateSpecializationDecl(
VarTemplateSpecializationDecl *D) {
+ // FIXME: We need to load the "logical" first declaration before writing
+ // the Redeclar
ChuanqiXu9 wrote:
I think now I understand the problem. The root cause happens in
https://github.com/llvm/llvm-project/blob/175aa864f33786f3a6a4ee7381cbcafd0758501a/clang/lib/Serialization/MultiOnDiskHashTable.h#L329
The description in () is optional. You can skip it if you're not interested it
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/83237
>From f2e53e44eebab4720a1dbade24fcb14d698fb03f Mon Sep 17 00:00:00 2001
From: Chuanqi Xu
Date: Wed, 28 Feb 2024 11:41:53 +0800
Subject: [PATCH 1/6] [Serialization] Code cleanups and polish 83233
---
clang/in
ChuanqiXu9 wrote:
> Here is the reproducer. Like before, builds at head and fails with the patch
> applied. After unpacking the archive just run
>
> ```
> $ CLANGPP= ./build.sh
> ```
>
> Note the comment in `build.sh` about the system libc++ required for it
> (libc++ 17 worked, 15 and 16 did
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/83237
>From f2e53e44eebab4720a1dbade24fcb14d698fb03f Mon Sep 17 00:00:00 2001
From: Chuanqi Xu
Date: Wed, 28 Feb 2024 11:41:53 +0800
Subject: [PATCH 1/4] [Serialization] Code cleanups and polish 83233
---
clang/in
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/83237
>From f2e53e44eebab4720a1dbade24fcb14d698fb03f Mon Sep 17 00:00:00 2001
From: Chuanqi Xu
Date: Wed, 28 Feb 2024 11:41:53 +0800
Subject: [PATCH 1/3] [Serialization] Code cleanups and polish 83233
---
clang/in
ChuanqiXu9 wrote:
> @ChuanqiXu9, is there anything else that needs to be done here? There's a
> merge conflict; I could resolve that.
If there is merge conflict, we need to resolve it. For the merge request, we
need to wait for the release manager to have a time to look at this. Maybe due
to
https://github.com/ChuanqiXu9 milestoned
https://github.com/llvm/llvm-project/pull/102438
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
ChuanqiXu9 wrote:
> > How about waiting 2 weeks to see if there is any regression reports? If no,
> > I'll try to ping you again to merge this.
>
> That seems counter-intuitive. Yes there are projects using LLVM main, but it
> would appear much more likely to me to get regression reports from
ChuanqiXu9 wrote:
> @ChuanqiXu9 are we good to merge this? It seems like a pretty big patch but
> reading the description it seems like some good fixes in there. Any risk
> taking this on?
Yes, this is not small. And I am 100% sure it is fine. But given this is
important, I still like to back
ChuanqiXu9 wrote:
I landed this directly as the owner of serialization. I feel this change is not
riskful as it adds more conditions to generate a diagnose message we didn't do
in 18.x and before. So nothing will be worse.
https://github.com/llvm/llvm-project/pull/102425
__
@@ -5,7 +5,7 @@
define nonnull ptr @f(i32 %n) presplitcoroutine {
; CHECK-LABEL: @f(
; CHECK-NEXT: entry:
-; CHECK-NEXT:[[ID:%.*]] = call token @llvm.coro.id(i32 0, ptr null, ptr
null, ptr @f.resumers)
+; CHECK-NEXT:[[ID:%.*]] = call token @llvm.coro.id(i32 0, ptr nul
@@ -1455,6 +1462,62 @@ struct SwitchCoroutineSplitter {
setCoroInfo(F, Shape, Clones);
}
+ static Function *createNoAllocVariant(Function &F, coro::Shape &Shape,
+SmallVectorImpl &Clones) {
+auto *OrigFnTy = F.getFunctionType(
ChuanqiXu9 wrote:
After I took a quick look at https://github.com/llvm/llvm-project/pull/99285, I
feel this is not what I thought when I heard the idea. Correct me if I
misunderstand it.
The problems are:
1. It looks like all the `.noalloc` variant are emitted all the time. This is
absolutely
@@ -0,0 +1,136 @@
+//===- CoroSplit.cpp - Converts a coroutine into a state machine
--===//
+//
+// 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: Ap
https://github.com/ChuanqiXu9 commented:
I did a quick scanning and I'll put the comment in
https://github.com/llvm/llvm-project/pull/99283#pullrequestreview-822800
https://github.com/llvm/llvm-project/pull/99285
___
llvm-branch-commits mailing li
https://github.com/ChuanqiXu9 edited
https://github.com/llvm/llvm-project/pull/99285
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -5,7 +5,7 @@
define nonnull ptr @f(i32 %n) presplitcoroutine {
; CHECK-LABEL: @f(
; CHECK-NEXT: entry:
-; CHECK-NEXT:[[ID:%.*]] = call token @llvm.coro.id(i32 0, ptr null, ptr
null, ptr @f.resumers)
+; CHECK-NEXT:[[ID:%.*]] = call token @llvm.coro.id(i32 0, ptr nul
@@ -1455,6 +1462,64 @@ struct SwitchCoroutineSplitter {
setCoroInfo(F, Shape, Clones);
}
+ static Function *createNoAllocVariant(Function &F, coro::Shape &Shape,
+SmallVectorImpl &Clones) {
+auto *OrigFnTy = F.getFunctionType(
@@ -63,6 +63,13 @@ suspend:
; CHECK-NOT: call void @free(
; CHECK: ret void
+; CHECK-LABEL: @f.noalloc({{.*}})
ChuanqiXu9 wrote:
I think it worth to list the arguments explicitly.
https://github.com/llvm/llvm-project/pull/99283
__
@@ -1967,22 +2047,13 @@ splitCoroutine(Function &F, SmallVectorImpl
&Clones,
for (DbgVariableRecord *DVR : DbgVariableRecords)
coro::salvageDebugInfo(ArgToAllocaMap, *DVR, Shape.OptimizeFrame,
false /*UseEntryValue*/);
- return Shape;
-}
-//
https://github.com/ChuanqiXu9 edited
https://github.com/llvm/llvm-project/pull/99283
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -1455,6 +1462,62 @@ struct SwitchCoroutineSplitter {
setCoroInfo(F, Shape, Clones);
}
+ static Function *createNoAllocVariant(Function &F, coro::Shape &Shape,
+SmallVectorImpl &Clones) {
+auto *OrigFnTy = F.getFunctionType(
https://github.com/ChuanqiXu9 commented:
We need to update coroutines.rst for such changes.
https://github.com/llvm/llvm-project/pull/99283
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/l
@@ -1455,6 +1462,62 @@ struct SwitchCoroutineSplitter {
setCoroInfo(F, Shape, Clones);
}
+ static Function *createNoAllocVariant(Function &F, coro::Shape &Shape,
ChuanqiXu9 wrote:
We need comment and an example for this function
https://github.com/llv
ChuanqiXu9 wrote:
I feel this is good and no risks to bring in 19.x
https://github.com/llvm/llvm-project/pull/102159
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-com
ChuanqiXu9 wrote:
> We've hit an error during testing:
>
> ```c++
> In module '...stl_cc_library':
> .../src/libcxx/include/__memory/allocator.h:128:60: error:
> 'std::allocator>::deallocate' from
> module '...stl_cc_library./cxx17/vector' is not present in definition of
> 'std::allocator>' p
ChuanqiXu9 wrote:
> > > @ilya-biryukov, could we have another try of this PR on your end?
> >
> >
> > Sorry for missing this, we will rerun the testing and get back to you.
>
> In the meantime, could you rebase the patch on top of current ToT?
Are you saying to rebase on your local branch? Si
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/83237
>From f2e53e44eebab4720a1dbade24fcb14d698fb03f Mon Sep 17 00:00:00 2001
From: Chuanqi Xu
Date: Wed, 28 Feb 2024 11:41:53 +0800
Subject: [PATCH 1/2] [Serialization] Code cleanups and polish 83233
---
clang/in
ChuanqiXu9 wrote:
@vgvassilev In the newest version, I introduced a new hasher
TemplateArgumentHasher and use this new hasher to calculate the hash value for
template arguments. We thought this may be harder. But I just realized, we
don't have to provide a very precise results at first. Since
ChuanqiXu9 wrote:
@ilya-biryukov I've fixed the crash occured in the reproducer. The root reason
is that, previously, I wouldn't load all the specializations for paritial
specializations. But this is not safe. I think you can test it again.
https://github.com/llvm/llvm-project/pull/83237
_
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/83237
>From f2e53e44eebab4720a1dbade24fcb14d698fb03f Mon Sep 17 00:00:00 2001
From: Chuanqi Xu
Date: Wed, 28 Feb 2024 11:41:53 +0800
Subject: [PATCH] [Serialization] Code cleanups and polish 83233
---
clang/includ
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/83233
>From 2bf5a6ca8bde003b7acf0a9ab7c6e69cc3109e02 Mon Sep 17 00:00:00 2001
From: Chuanqi Xu
Date: Wed, 28 Feb 2024 11:41:53 +0800
Subject: [PATCH] [Serialization] Introduce OnDiskHashTable for specializations
Fo
ChuanqiXu9 wrote:
Sorry for bothering, I tried a new manner to update the patch but it shows I
should better : (
https://github.com/llvm/llvm-project/pull/83237
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm
https://github.com/ChuanqiXu9 updated
https://github.com/llvm/llvm-project/pull/83233
error: too big or took too long to generate
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/ll
@@ -70,38 +71,53 @@ using DeclID = DeclIDBase::DeclID;
/// An ID number that refers to a type in an AST file.
///
-/// The ID of a type is partitioned into two parts: the lower
+/// The ID of a type is partitioned into three parts:
+/// - the lower
/// three bits are used to
@@ -70,38 +71,53 @@ using DeclID = DeclIDBase::DeclID;
/// An ID number that refers to a type in an AST file.
///
-/// The ID of a type is partitioned into two parts: the lower
+/// The ID of a type is partitioned into three parts:
+/// - the lower
/// three bits are used to
@@ -7650,6 +7647,16 @@ ModuleFile *ASTReader::getOwningModuleFile(GlobalDeclID
ID) const {
return &getModuleManager()[ModuleFileIndex - 1];
}
+ModuleFile *ASTReader::getOwningModuleFile(TypeID ID) const {
+ if (ID < NUM_PREDEF_TYPE_IDS)
+return nullptr;
+
+ uint64_t M
@@ -3262,17 +3262,18 @@ void ASTWriter::WritePragmaDiagnosticMappings(const
DiagnosticsEngine &Diag,
/// Write the representation of a type to the AST stream.
void ASTWriter::WriteType(QualType T) {
TypeIdx &IdxRef = TypeIdxs[T];
- if (IdxRef.getIndex() == 0) // we haven't
@@ -6659,13 +6655,22 @@ void ASTWriter::MacroRead(serialization::MacroID ID,
MacroInfo *MI) {
}
void ASTWriter::TypeRead(TypeIdx Idx, QualType T) {
- // Always take the highest-numbered type index. This copes with an
interesting
+ // Always take the type index that comes i
1 - 100 of 167 matches
Mail list logo
