@@ -857,8 +881,13 @@ void CXXRecordDecl::addedMember(Decl *D) {
data().HasDeclaredCopyAssignmentWithConstParam = true;
}
-if (Method->isMoveAssignmentOperator())
+if (Method->isMoveAssignmentOperator()) {
SMKind |= SMF_MoveAssignment;
+}
+
+i
@@ -826,6 +842,14 @@ void CXXRecordDecl::addedMember(Decl *D) {
? !Constructor->isImplicit()
: (Constructor->isUserProvided() || Constructor->isExplicit()))
data().Aggregate = false;
+
+ // A trivially relocatable class is a class:
+
https://github.com/sdkrystian commented:
Minor nit, but otherwise looks good.
https://github.com/llvm/llvm-project/pull/84621
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
alandefreitas wrote:
My Boost libraries would benefit a lot from this change. 🙂
https://github.com/llvm/llvm-project/pull/84621
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -857,8 +881,13 @@ void CXXRecordDecl::addedMember(Decl *D) {
data().HasDeclaredCopyAssignmentWithConstParam = true;
}
-if (Method->isMoveAssignmentOperator())
+if (Method->isMoveAssignmentOperator()) {
SMKind |= SMF_MoveAssignment;
+}
+
+i
https://github.com/AMP999 updated
https://github.com/llvm/llvm-project/pull/84621
>From 6e127e5794efafaabf82b6c3d5e0634ddcfee977 Mon Sep 17 00:00:00 2001
From: Amirreza Ashouri
Date: Sat, 2 Mar 2024 15:37:33 +0330
Subject: [PATCH 1/4] [clang][Sema] Track trivial-relocatability as a type
trait
@@ -857,8 +881,13 @@ void CXXRecordDecl::addedMember(Decl *D) {
data().HasDeclaredCopyAssignmentWithConstParam = true;
}
-if (Method->isMoveAssignmentOperator())
+if (Method->isMoveAssignmentOperator()) {
SMKind |= SMF_MoveAssignment;
+}
https://github.com/AMP999 edited https://github.com/llvm/llvm-project/pull/84621
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -826,6 +842,14 @@ void CXXRecordDecl::addedMember(Decl *D) {
? !Constructor->isImplicit()
: (Constructor->isUserProvided() || Constructor->isExplicit()))
data().Aggregate = false;
+
+ // A trivially relocatable class is a class:
+
@@ -2680,8 +2680,8 @@ bool QualType::isTriviallyRelocatableType(const
ASTContext &Context) const {
return false;
} else if (!BaseElementType->isObjectType()) {
return false;
- } else if (const auto *RD = BaseElementType->getAsRecordDecl()) {
-return RD->canPassI
https://github.com/AMP999 updated
https://github.com/llvm/llvm-project/pull/84621
>From 6e127e5794efafaabf82b6c3d5e0634ddcfee977 Mon Sep 17 00:00:00 2001
From: Amirreza Ashouri
Date: Sat, 2 Mar 2024 15:37:33 +0330
Subject: [PATCH 1/5] [clang][Sema] Track trivial-relocatability as a type
trait
DanielLiamAnderson wrote:
This would be really useful for
[ParlayLib](https://github.com/cmuparlay/parlaylib). We implement our own
is_trivially_relocatable which is not nearly as reliable as having the compiler
do it. I support this PR's semantics; types with non-defaulted assignment
operato
sjanel wrote:
The [amc](https://github.com/AmadeusITGroup/amc) library defining drop-in
replacement for vector-like containers handling trivially relocatability
optimizations would love to see this kind of improvement, as currently the
users need to manually tell the compiler which types are O
isidorostsa wrote:
Currently, [HPX](https://github.com/STEllAR-GROUP/hpx) implements the P1144
interface. We have our own implementation of the is_trivially_relocatable
trait, but it cannot recursively figure out if a type is relocatable based on
its components. It would be great for us to let
danakj wrote:
The subspace library also provides mechanisms [for
querying](https://suslib.cc/sus-mem-TriviallyRelocatable.html) and marking
types trivially relocatable, and relies on the compiler's
`__is_trivially_relocatable` as a signal as well. It then optimizes containers
and operations i
arturbac wrote:
My small_vectors are waiting for that feature for a long time, already have
trait defined but cant implement and TODO in code.
https://github.com/llvm/llvm-project/pull/84621
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http
@@ -857,8 +881,13 @@ void CXXRecordDecl::addedMember(Decl *D) {
data().HasDeclaredCopyAssignmentWithConstParam = true;
}
-if (Method->isMoveAssignmentOperator())
+if (Method->isMoveAssignmentOperator()) {
SMKind |= SMF_MoveAssignment;
+}
+
+i
https://github.com/cor3ntin edited
https://github.com/llvm/llvm-project/pull/84621
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
cor3ntin wrote:
> The semantics in this PR are the semantics relied upon by the libraries whose
> maintainers have commented in support of this PR. These semantics have been
> codified into P1144; that's the paper I'm quoting in the code comments.
> @cor3ntin could you clarify what you mean by
AaronBallman wrote:
Based on the poll results from Tokyo, P2786 is the direction EWG has taken for
this functionality, so we should be focusing our efforts on supporting that
direction. If WG21 changes direction again, we can shift again, (this builtin
exists to support the standard's type tra
@@ -826,6 +842,14 @@ void CXXRecordDecl::addedMember(Decl *D) {
? !Constructor->isImplicit()
: (Constructor->isUserProvided() || Constructor->isExplicit()))
data().Aggregate = false;
+
+ // A trivially relocatable class is a class:
+
dangelog wrote:
I perfectly understand that Clang wants to implement the semantics that are
being adopted by standard C++, so it wants to reserve
`__is_trivially_relocatable` to match those semantics.
The amount of comments in this PR is however a strong signal that standard C++
is going dire
cor3ntin wrote:
> But this isn't useful at all; every library has already invented its own
> constraints and type traits. The point of having a language-based solution is
> that the "is TR" property gets automatically propagated when you compose
> types. No library solution can achieve that, e
cor3ntin wrote:
> Do you mean that you would reject a proposal that adds Clang-specific trait
> (with another name) that implements P1144's semantics?
A proposal that explores trivial swapability for example, with the
understanding it would be a subset of trivially relocatable types might be
AaronBallman wrote:
> Do you mean that you would reject a proposal that adds Clang-specific trait
> (with another name) that implements P1144's semantics?
So long as it checks all the boxes in our usual
[criteria](https://clang.llvm.org/get_involved.html#criteria) for extensions,
I'd see no r
https://github.com/AMP999 created
https://github.com/llvm/llvm-project/pull/84621
To resolve llvm#69394, this patch separates trivial-relocatability's logic from
`canPassInRegisters` to decide if a type is trivial-relocatable. A type passed
in registers doesn't necessarily mean trivial-relocat
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Amirreza Ashouri (AMP999)
Changes
To resolve llvm#69394, this patch separates trivial-relocatability's
logic from `canPassInRegisters` to decide if a type is trivial-relocatable. A
type passed in registers doesn't necessarily mean trivial
https://github.com/AMP999 updated
https://github.com/llvm/llvm-project/pull/84621
>From 71502300d47f3d5492e6073a3959fe32b0c9cf65 Mon Sep 17 00:00:00 2001
From: Amirreza Ashouri
Date: Sat, 2 Mar 2024 15:37:33 +0330
Subject: [PATCH] [clang][Sema] Track trivial-relocatability as a type trait
To r
https://github.com/AMP999 updated
https://github.com/llvm/llvm-project/pull/84621
>From 2603e170c127aa614d499e5d527db8503a55c651 Mon Sep 17 00:00:00 2001
From: Amirreza Ashouri
Date: Sat, 2 Mar 2024 15:37:33 +0330
Subject: [PATCH] [clang][Sema] Track trivial-relocatability as a type trait
To r
https://github.com/AMP999 updated
https://github.com/llvm/llvm-project/pull/84621
>From 2603e170c127aa614d499e5d527db8503a55c651 Mon Sep 17 00:00:00 2001
From: Amirreza Ashouri
Date: Sat, 2 Mar 2024 15:37:33 +0330
Subject: [PATCH] [clang][Sema] Track trivial-relocatability as a type trait
To r
https://github.com/AMP999 updated
https://github.com/llvm/llvm-project/pull/84621
>From 6e127e5794efafaabf82b6c3d5e0634ddcfee977 Mon Sep 17 00:00:00 2001
From: Amirreza Ashouri
Date: Sat, 2 Mar 2024 15:37:33 +0330
Subject: [PATCH 1/2] [clang][Sema] Track trivial-relocatability as a type
trait
github-actions[bot] wrote:
:warning: C/C++ code formatter, clang-format found issues in your code.
:warning:
You can test this locally with the following command:
``bash
git-clang-format --diff 3358838446428976a41390fde98fe5b04b08a132
a7ff71da99cd158e9bc608b43577cb854dfc7fae --
https://github.com/AMP999 updated
https://github.com/llvm/llvm-project/pull/84621
>From 6e127e5794efafaabf82b6c3d5e0634ddcfee977 Mon Sep 17 00:00:00 2001
From: Amirreza Ashouri
Date: Sat, 2 Mar 2024 15:37:33 +0330
Subject: [PATCH 1/3] [clang][Sema] Track trivial-relocatability as a type
trait
https://github.com/AMP999 updated
https://github.com/llvm/llvm-project/pull/84621
>From 6e127e5794efafaabf82b6c3d5e0634ddcfee977 Mon Sep 17 00:00:00 2001
From: Amirreza Ashouri
Date: Sat, 2 Mar 2024 15:37:33 +0330
Subject: [PATCH 1/3] [clang][Sema] Track trivial-relocatability as a type
trait
@@ -857,8 +881,13 @@ void CXXRecordDecl::addedMember(Decl *D) {
data().HasDeclaredCopyAssignmentWithConstParam = true;
}
-if (Method->isMoveAssignmentOperator())
+if (Method->isMoveAssignmentOperator()) {
SMKind |= SMF_MoveAssignment;
+}
+
+i
@@ -189,6 +189,11 @@ FIELD(DeclaredNonTrivialSpecialMembers, 6, MERGE_OR)
/// SMF_MoveConstructor, and SMF_Destructor are meaningful here.
FIELD(DeclaredNonTrivialSpecialMembersForCall, 6, MERGE_OR)
+/// True when this class's bases and fields are all trivially relocatable
+//
@@ -826,6 +842,14 @@ void CXXRecordDecl::addedMember(Decl *D) {
? !Constructor->isImplicit()
: (Constructor->isUserProvided() || Constructor->isExplicit()))
data().Aggregate = false;
+
+ // A trivially relocatable class is a class:
+
@@ -857,8 +881,13 @@ void CXXRecordDecl::addedMember(Decl *D) {
data().HasDeclaredCopyAssignmentWithConstParam = true;
}
-if (Method->isMoveAssignmentOperator())
+if (Method->isMoveAssignmentOperator()) {
SMKind |= SMF_MoveAssignment;
+}
rnk wrote:
So, I was completely unaware that trivial relocatability had been picked up at
all by WG21. Since the beginning of `trivial_abi`, I we were solidly in the
vendor-extension space trying to build non-standard but practical solutions to
real world problems, like the fact that we couldn
@@ -826,6 +842,14 @@ void CXXRecordDecl::addedMember(Decl *D) {
? !Constructor->isImplicit()
: (Constructor->isUserProvided() || Constructor->isExplicit()))
data().Aggregate = false;
+
+ // A trivially relocatable class is a class:
+
AaronBallman wrote:
> So, I was completely unaware that trivial relocatability had been picked up
> at all by WG21. Since the beginning of `trivial_abi`, I we were solidly in
> the vendor-extension space trying to build non-standard but practical
> solutions to real world problems, like the fa
QrczakMK wrote:
I think that if Clang chooses to support both variants of the type trait, it
should provide both variants of `[[clang::trivial_abi]]`, so that a type like
`std::unique_ptr` is trivially relocatable including assignment (and can be
annotated as such), while a type like `std::tup
AMP999 wrote:
> We (users & implementers) have all collectively identified trivial
> relocatability as an important optimization for vector-like containers, and
> we're all looking for a solution to that. It feels like this attempt to
> standardize this type trait is getting in the way of our
AaronBallman wrote:
> > We (users & implementers) have all collectively identified trivial
> > relocatability as an important optimization for vector-like containers, and
> > we're all looking for a solution to that. It feels like this attempt to
> > standardize this type trait is getting in t
44 matches
Mail list logo
