[clang] [ObjC] Defer to the LLVM backend for unaligned atomic load and stores (PR #79191)
jyknight wrote: > Don't know but everything passed now! Well, I'm not an expert on the objc codegen...but unless you, or someone else, can explain that my concern is invalid, I think this change cannot be made. https://github.com/llvm/llvm-project/pull/79191 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [ObjC] Defer to the LLVM backend for unaligned atomic load and stores (PR #79191)
https://github.com/AtariDreams updated
https://github.com/llvm/llvm-project/pull/79191
>From 1c54c1e9767e9a53fde23e5717b834b30b228867 Mon Sep 17 00:00:00 2001
From: Rose <83477269+ataridre...@users.noreply.github.com>
Date: Tue, 23 Jan 2024 13:59:05 -0500
Subject: [PATCH] [ObjC] Defer to the LLVM backend for unaligned atomic load
and stores
LLVM can codegen correctly for atomics of any alignment in IR, on any
architecture (via using libcalls when necessary).
So, the ObjC code's hasUnalignedAtomics can be removed. We can use copyStruct
if the size is too big.
---
clang/lib/CodeGen/CGObjC.cpp| 17 -
clang/test/CodeGenObjC/objc_copyStruct.m| 3 +--
clang/test/CodeGenObjC/property-aggregate.m | 15 ++-
3 files changed, 3 insertions(+), 32 deletions(-)
diff --git a/clang/lib/CodeGen/CGObjC.cpp b/clang/lib/CodeGen/CGObjC.cpp
index f3a948cf13f9c9..ccda7ce8f41b9f 100644
--- a/clang/lib/CodeGen/CGObjC.cpp
+++ b/clang/lib/CodeGen/CGObjC.cpp
@@ -842,15 +842,6 @@ static void emitStructGetterCall(CodeGenFunction ,
ObjCIvarDecl *ivar,
callee, ReturnValueSlot(), args);
}
-/// Determine whether the given architecture supports unaligned atomic
-/// accesses. They don't have to be fast, just faster than a function
-/// call and a mutex.
-static bool hasUnalignedAtomics(llvm::Triple::ArchType arch) {
- // FIXME: Allow unaligned atomic load/store on x86. (It is not
- // currently supported by the backend.)
- return false;
-}
-
/// Return the maximum size that permits atomic accesses for the given
/// architecture.
static CharUnits getMaxAtomicAccessSize(CodeGenModule ,
@@ -1023,14 +1014,6 @@ PropertyImplStrategy::PropertyImplStrategy(CodeGenModule
,
llvm::Triple::ArchType arch =
CGM.getTarget().getTriple().getArch();
- // Most architectures require memory to fit within a single cache
- // line, so the alignment has to be at least the size of the access.
- // Otherwise we have to grab a lock.
- if (IvarAlignment < IvarSize && !hasUnalignedAtomics(arch)) {
-Kind = CopyStruct;
-return;
- }
-
// If the ivar's size exceeds the architecture's maximum atomic
// access size, we have to use CopyStruct.
if (IvarSize > getMaxAtomicAccessSize(CGM, arch)) {
diff --git a/clang/test/CodeGenObjC/objc_copyStruct.m
b/clang/test/CodeGenObjC/objc_copyStruct.m
index 7bbad866e2b1fb..8e52815a308abc 100644
--- a/clang/test/CodeGenObjC/objc_copyStruct.m
+++ b/clang/test/CodeGenObjC/objc_copyStruct.m
@@ -2,7 +2,7 @@
// RUN: %clang -target x86_64-apple-ios -fobjc-runtime=ios
-Wno-objc-root-class -S -o - -emit-llvm %s | FileCheck %s
struct S {
- float f, g;
+ double f, g;
};
@interface I
@@ -13,4 +13,3 @@ @implementation I
@end
// CHECK: declare {{.*}}void @objc_copyStruct(ptr, ptr, i64, i1, i1)
-
diff --git a/clang/test/CodeGenObjC/property-aggregate.m
b/clang/test/CodeGenObjC/property-aggregate.m
index f4211b6b62bd50..4c8c8893f920f4 100644
--- a/clang/test/CodeGenObjC/property-aggregate.m
+++ b/clang/test/CodeGenObjC/property-aggregate.m
@@ -1,13 +1,8 @@
// RUN: %clang_cc1 -triple x86_64-apple-darwin -emit-llvm %s -o - | FileCheck
%s
-// This structure's size is not a power of two, so the property does
-// not get native atomics, even though x86-64 can do unaligned atomics
-// with a lock prefix.
struct s3 { char c[3]; };
// This structure's size is, so it does, because it can.
-// FIXME: But we don't at the moment; the backend doesn't know how to generate
-// correct code.
struct s4 { char c[4]; };
@interface Test0
@@ -18,14 +13,8 @@ @implementation Test0
@synthesize s3, s4;
@end
-// CHECK: define internal i24 @"\01-[Test0 s3]"(
-// CHECK: call void @objc_copyStruct
-// CHECK: define internal void @"\01-[Test0 setS3:]"(
-// CHECK: call void @objc_copyStruct
-// CHECK: define internal i32 @"\01-[Test0 s4]"(
-// CHECK: call void @objc_copyStruct
-// CHECK: define internal void @"\01-[Test0 setS4:]"(
-// CHECK: call void @objc_copyStruct
+ NOTE: These prefixes are unused and the list is autogenerated. Do not add
tests below this line:
+// CHECK: {{.*}}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [ObjC] Defer to the LLVM backend for unaligned atomic load and stores (PR #79191)
https://github.com/AtariDreams updated
https://github.com/llvm/llvm-project/pull/79191
>From 6644009297d1024a14fe27c941217add323079ea Mon Sep 17 00:00:00 2001
From: Rose <83477269+ataridre...@users.noreply.github.com>
Date: Tue, 23 Jan 2024 13:59:05 -0500
Subject: [PATCH] [ObjC] Defer to the LLVM backend for unaligned atomic load
and stores
LLVM can codegen correctly for atomics of any alignment in IR, on any
architecture (via using libcalls when necessary).
So, the ObjC code's hasUnalignedAtomics can be removed. We can use copyStruct
if the size is too big.
---
clang/lib/CodeGen/CGObjC.cpp| 17 -
clang/test/CodeGenObjC/objc_copyStruct.m| 3 +--
clang/test/CodeGenObjC/property-aggregate.m | 15 ++-
3 files changed, 3 insertions(+), 32 deletions(-)
diff --git a/clang/lib/CodeGen/CGObjC.cpp b/clang/lib/CodeGen/CGObjC.cpp
index f3a948cf13f9c9..ccda7ce8f41b9f 100644
--- a/clang/lib/CodeGen/CGObjC.cpp
+++ b/clang/lib/CodeGen/CGObjC.cpp
@@ -842,15 +842,6 @@ static void emitStructGetterCall(CodeGenFunction ,
ObjCIvarDecl *ivar,
callee, ReturnValueSlot(), args);
}
-/// Determine whether the given architecture supports unaligned atomic
-/// accesses. They don't have to be fast, just faster than a function
-/// call and a mutex.
-static bool hasUnalignedAtomics(llvm::Triple::ArchType arch) {
- // FIXME: Allow unaligned atomic load/store on x86. (It is not
- // currently supported by the backend.)
- return false;
-}
-
/// Return the maximum size that permits atomic accesses for the given
/// architecture.
static CharUnits getMaxAtomicAccessSize(CodeGenModule ,
@@ -1023,14 +1014,6 @@ PropertyImplStrategy::PropertyImplStrategy(CodeGenModule
,
llvm::Triple::ArchType arch =
CGM.getTarget().getTriple().getArch();
- // Most architectures require memory to fit within a single cache
- // line, so the alignment has to be at least the size of the access.
- // Otherwise we have to grab a lock.
- if (IvarAlignment < IvarSize && !hasUnalignedAtomics(arch)) {
-Kind = CopyStruct;
-return;
- }
-
// If the ivar's size exceeds the architecture's maximum atomic
// access size, we have to use CopyStruct.
if (IvarSize > getMaxAtomicAccessSize(CGM, arch)) {
diff --git a/clang/test/CodeGenObjC/objc_copyStruct.m
b/clang/test/CodeGenObjC/objc_copyStruct.m
index 7bbad866e2b1fb..8e52815a308abc 100644
--- a/clang/test/CodeGenObjC/objc_copyStruct.m
+++ b/clang/test/CodeGenObjC/objc_copyStruct.m
@@ -2,7 +2,7 @@
// RUN: %clang -target x86_64-apple-ios -fobjc-runtime=ios
-Wno-objc-root-class -S -o - -emit-llvm %s | FileCheck %s
struct S {
- float f, g;
+ double f, g;
};
@interface I
@@ -13,4 +13,3 @@ @implementation I
@end
// CHECK: declare {{.*}}void @objc_copyStruct(ptr, ptr, i64, i1, i1)
-
diff --git a/clang/test/CodeGenObjC/property-aggregate.m
b/clang/test/CodeGenObjC/property-aggregate.m
index f4211b6b62bd50..4c8c8893f920f4 100644
--- a/clang/test/CodeGenObjC/property-aggregate.m
+++ b/clang/test/CodeGenObjC/property-aggregate.m
@@ -1,13 +1,8 @@
// RUN: %clang_cc1 -triple x86_64-apple-darwin -emit-llvm %s -o - | FileCheck
%s
-// This structure's size is not a power of two, so the property does
-// not get native atomics, even though x86-64 can do unaligned atomics
-// with a lock prefix.
struct s3 { char c[3]; };
// This structure's size is, so it does, because it can.
-// FIXME: But we don't at the moment; the backend doesn't know how to generate
-// correct code.
struct s4 { char c[4]; };
@interface Test0
@@ -18,14 +13,8 @@ @implementation Test0
@synthesize s3, s4;
@end
-// CHECK: define internal i24 @"\01-[Test0 s3]"(
-// CHECK: call void @objc_copyStruct
-// CHECK: define internal void @"\01-[Test0 setS3:]"(
-// CHECK: call void @objc_copyStruct
-// CHECK: define internal i32 @"\01-[Test0 s4]"(
-// CHECK: call void @objc_copyStruct
-// CHECK: define internal void @"\01-[Test0 setS4:]"(
-// CHECK: call void @objc_copyStruct
+ NOTE: These prefixes are unused and the list is autogenerated. Do not add
tests below this line:
+// CHECK: {{.*}}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [ObjC] Defer to the LLVM backend for unaligned atomic load and stores (PR #79191)
https://github.com/AtariDreams updated
https://github.com/llvm/llvm-project/pull/79191
>From 83ad8677e5e5c641505806b411216ddc8588d712 Mon Sep 17 00:00:00 2001
From: Rose <83477269+ataridre...@users.noreply.github.com>
Date: Tue, 23 Jan 2024 13:59:05 -0500
Subject: [PATCH] [ObjC] Defer to the LLVM backend for unaligned atomic load
and stores
LLVM can codegen correctly for atomics of any alignment in IR, on any
architecture (via using libcalls when necessary).
So, the ObjC code's hasUnalignedAtomics can be removed. We can use copyStruct
if the size is too big.
---
clang/lib/CodeGen/CGObjC.cpp| 17 -
clang/test/CodeGenObjC/objc_copyStruct.m| 3 +--
clang/test/CodeGenObjC/property-aggregate.m | 15 ++-
3 files changed, 3 insertions(+), 32 deletions(-)
diff --git a/clang/lib/CodeGen/CGObjC.cpp b/clang/lib/CodeGen/CGObjC.cpp
index f3a948cf13f9c9..ccda7ce8f41b9f 100644
--- a/clang/lib/CodeGen/CGObjC.cpp
+++ b/clang/lib/CodeGen/CGObjC.cpp
@@ -842,15 +842,6 @@ static void emitStructGetterCall(CodeGenFunction ,
ObjCIvarDecl *ivar,
callee, ReturnValueSlot(), args);
}
-/// Determine whether the given architecture supports unaligned atomic
-/// accesses. They don't have to be fast, just faster than a function
-/// call and a mutex.
-static bool hasUnalignedAtomics(llvm::Triple::ArchType arch) {
- // FIXME: Allow unaligned atomic load/store on x86. (It is not
- // currently supported by the backend.)
- return false;
-}
-
/// Return the maximum size that permits atomic accesses for the given
/// architecture.
static CharUnits getMaxAtomicAccessSize(CodeGenModule ,
@@ -1023,14 +1014,6 @@ PropertyImplStrategy::PropertyImplStrategy(CodeGenModule
,
llvm::Triple::ArchType arch =
CGM.getTarget().getTriple().getArch();
- // Most architectures require memory to fit within a single cache
- // line, so the alignment has to be at least the size of the access.
- // Otherwise we have to grab a lock.
- if (IvarAlignment < IvarSize && !hasUnalignedAtomics(arch)) {
-Kind = CopyStruct;
-return;
- }
-
// If the ivar's size exceeds the architecture's maximum atomic
// access size, we have to use CopyStruct.
if (IvarSize > getMaxAtomicAccessSize(CGM, arch)) {
diff --git a/clang/test/CodeGenObjC/objc_copyStruct.m
b/clang/test/CodeGenObjC/objc_copyStruct.m
index 7bbad866e2b1fb..8e52815a308abc 100644
--- a/clang/test/CodeGenObjC/objc_copyStruct.m
+++ b/clang/test/CodeGenObjC/objc_copyStruct.m
@@ -2,7 +2,7 @@
// RUN: %clang -target x86_64-apple-ios -fobjc-runtime=ios
-Wno-objc-root-class -S -o - -emit-llvm %s | FileCheck %s
struct S {
- float f, g;
+ double f, g;
};
@interface I
@@ -13,4 +13,3 @@ @implementation I
@end
// CHECK: declare {{.*}}void @objc_copyStruct(ptr, ptr, i64, i1, i1)
-
diff --git a/clang/test/CodeGenObjC/property-aggregate.m
b/clang/test/CodeGenObjC/property-aggregate.m
index f4211b6b62bd50..4c8c8893f920f4 100644
--- a/clang/test/CodeGenObjC/property-aggregate.m
+++ b/clang/test/CodeGenObjC/property-aggregate.m
@@ -1,13 +1,8 @@
// RUN: %clang_cc1 -triple x86_64-apple-darwin -emit-llvm %s -o - | FileCheck
%s
-// This structure's size is not a power of two, so the property does
-// not get native atomics, even though x86-64 can do unaligned atomics
-// with a lock prefix.
struct s3 { char c[3]; };
// This structure's size is, so it does, because it can.
-// FIXME: But we don't at the moment; the backend doesn't know how to generate
-// correct code.
struct s4 { char c[4]; };
@interface Test0
@@ -18,14 +13,8 @@ @implementation Test0
@synthesize s3, s4;
@end
-// CHECK: define internal i24 @"\01-[Test0 s3]"(
-// CHECK: call void @objc_copyStruct
-// CHECK: define internal void @"\01-[Test0 setS3:]"(
-// CHECK: call void @objc_copyStruct
-// CHECK: define internal i32 @"\01-[Test0 s4]"(
-// CHECK: call void @objc_copyStruct
-// CHECK: define internal void @"\01-[Test0 setS4:]"(
-// CHECK: call void @objc_copyStruct
+ NOTE: These prefixes are unused and the list is autogenerated. Do not add
tests below this line:
+// CHECK: {{.*}}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [ObjC] Defer to the LLVM backend for unaligned atomic load and stores (PR #79191)
https://github.com/AtariDreams updated
https://github.com/llvm/llvm-project/pull/79191
>From ea42a83c26d6f5d8bd562a2f67586ab90554e539 Mon Sep 17 00:00:00 2001
From: Rose <83477269+ataridre...@users.noreply.github.com>
Date: Tue, 23 Jan 2024 13:59:05 -0500
Subject: [PATCH] [ObjC] Defer to the LLVM backend for unaligned atomic load
and stores
LLVM can codegen correctly for atomics of any alignment in IR, on any
architecture (via using libcalls when necessary).
So, the ObjC code's hasUnalignedAtomics can be removed. We can use copyStruct
if the size is too big.
---
clang/lib/CodeGen/CGObjC.cpp| 17 -
clang/test/CodeGenObjC/objc_copyStruct.m| 3 +--
clang/test/CodeGenObjC/property-aggregate.m | 15 ++-
3 files changed, 3 insertions(+), 32 deletions(-)
diff --git a/clang/lib/CodeGen/CGObjC.cpp b/clang/lib/CodeGen/CGObjC.cpp
index f3a948cf13f9c9..ccda7ce8f41b9f 100644
--- a/clang/lib/CodeGen/CGObjC.cpp
+++ b/clang/lib/CodeGen/CGObjC.cpp
@@ -842,15 +842,6 @@ static void emitStructGetterCall(CodeGenFunction ,
ObjCIvarDecl *ivar,
callee, ReturnValueSlot(), args);
}
-/// Determine whether the given architecture supports unaligned atomic
-/// accesses. They don't have to be fast, just faster than a function
-/// call and a mutex.
-static bool hasUnalignedAtomics(llvm::Triple::ArchType arch) {
- // FIXME: Allow unaligned atomic load/store on x86. (It is not
- // currently supported by the backend.)
- return false;
-}
-
/// Return the maximum size that permits atomic accesses for the given
/// architecture.
static CharUnits getMaxAtomicAccessSize(CodeGenModule ,
@@ -1023,14 +1014,6 @@ PropertyImplStrategy::PropertyImplStrategy(CodeGenModule
,
llvm::Triple::ArchType arch =
CGM.getTarget().getTriple().getArch();
- // Most architectures require memory to fit within a single cache
- // line, so the alignment has to be at least the size of the access.
- // Otherwise we have to grab a lock.
- if (IvarAlignment < IvarSize && !hasUnalignedAtomics(arch)) {
-Kind = CopyStruct;
-return;
- }
-
// If the ivar's size exceeds the architecture's maximum atomic
// access size, we have to use CopyStruct.
if (IvarSize > getMaxAtomicAccessSize(CGM, arch)) {
diff --git a/clang/test/CodeGenObjC/objc_copyStruct.m
b/clang/test/CodeGenObjC/objc_copyStruct.m
index 7bbad866e2b1fb..8e52815a308abc 100644
--- a/clang/test/CodeGenObjC/objc_copyStruct.m
+++ b/clang/test/CodeGenObjC/objc_copyStruct.m
@@ -2,7 +2,7 @@
// RUN: %clang -target x86_64-apple-ios -fobjc-runtime=ios
-Wno-objc-root-class -S -o - -emit-llvm %s | FileCheck %s
struct S {
- float f, g;
+ double f, g;
};
@interface I
@@ -13,4 +13,3 @@ @implementation I
@end
// CHECK: declare {{.*}}void @objc_copyStruct(ptr, ptr, i64, i1, i1)
-
diff --git a/clang/test/CodeGenObjC/property-aggregate.m
b/clang/test/CodeGenObjC/property-aggregate.m
index f4211b6b62bd50..4c8c8893f920f4 100644
--- a/clang/test/CodeGenObjC/property-aggregate.m
+++ b/clang/test/CodeGenObjC/property-aggregate.m
@@ -1,13 +1,8 @@
// RUN: %clang_cc1 -triple x86_64-apple-darwin -emit-llvm %s -o - | FileCheck
%s
-// This structure's size is not a power of two, so the property does
-// not get native atomics, even though x86-64 can do unaligned atomics
-// with a lock prefix.
struct s3 { char c[3]; };
// This structure's size is, so it does, because it can.
-// FIXME: But we don't at the moment; the backend doesn't know how to generate
-// correct code.
struct s4 { char c[4]; };
@interface Test0
@@ -18,14 +13,8 @@ @implementation Test0
@synthesize s3, s4;
@end
-// CHECK: define internal i24 @"\01-[Test0 s3]"(
-// CHECK: call void @objc_copyStruct
-// CHECK: define internal void @"\01-[Test0 setS3:]"(
-// CHECK: call void @objc_copyStruct
-// CHECK: define internal i32 @"\01-[Test0 s4]"(
-// CHECK: call void @objc_copyStruct
-// CHECK: define internal void @"\01-[Test0 setS4:]"(
-// CHECK: call void @objc_copyStruct
+ NOTE: These prefixes are unused and the list is autogenerated. Do not add
tests below this line:
+// CHECK: {{.*}}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [ObjC] Defer to the LLVM backend for unaligned atomic load and stores (PR #79191)
AtariDreams wrote: > Does this cause an ABI incompatibility? E.g. if we have a case where an > existing object calls copyStruct on a given object (which presumably has its > own internal mutex), and a newly compiled object file calls `__atomic_load` > on the same object, implemented with its own internal mutex, the operations > won't be atomic w.r.t. each-other. > > I don't know enough about ObjC codegen stuff to be able to say if there are > mitigating factors that make this OK (e.g. if it's all within one TU?). > > Sidenote: please avoid rebase, amend, and force-pushing, because it makes it > hard to review what's been changed -- instead, just keep adding more commits > to your pull-request branch. Don't know but everything passed now! https://github.com/llvm/llvm-project/pull/79191 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [ObjC] Defer to the LLVM backend for unaligned atomic load and stores (PR #79191)
https://github.com/AtariDreams updated
https://github.com/llvm/llvm-project/pull/79191
>From 03f8dddefffa8a3c3e01dd00db3f65052ba959fb Mon Sep 17 00:00:00 2001
From: Rose <83477269+ataridre...@users.noreply.github.com>
Date: Tue, 23 Jan 2024 13:59:05 -0500
Subject: [PATCH] [ObjC] Defer to the LLVM backend for unaligned atomic load
and stores
LLVM can codegen correctly for atomics of any alignment in IR, on any
architecture (via using libcalls when necessary).
So, the ObjC code's hasUnalignedAtomics can be removed. We can use copyStruct
if the size is too big.
---
clang/lib/CodeGen/CGObjC.cpp| 17 -
clang/test/CodeGenObjC/objc_copyStruct.m| 3 +--
clang/test/CodeGenObjC/property-aggregate.m | 15 ++-
3 files changed, 3 insertions(+), 32 deletions(-)
diff --git a/clang/lib/CodeGen/CGObjC.cpp b/clang/lib/CodeGen/CGObjC.cpp
index 03fc0ec7ff54e1..353807fedf090a 100644
--- a/clang/lib/CodeGen/CGObjC.cpp
+++ b/clang/lib/CodeGen/CGObjC.cpp
@@ -842,15 +842,6 @@ static void emitStructGetterCall(CodeGenFunction ,
ObjCIvarDecl *ivar,
callee, ReturnValueSlot(), args);
}
-/// Determine whether the given architecture supports unaligned atomic
-/// accesses. They don't have to be fast, just faster than a function
-/// call and a mutex.
-static bool hasUnalignedAtomics(llvm::Triple::ArchType arch) {
- // FIXME: Allow unaligned atomic load/store on x86. (It is not
- // currently supported by the backend.)
- return false;
-}
-
/// Return the maximum size that permits atomic accesses for the given
/// architecture.
static CharUnits getMaxAtomicAccessSize(CodeGenModule ,
@@ -1019,14 +1010,6 @@ PropertyImplStrategy::PropertyImplStrategy(CodeGenModule
,
llvm::Triple::ArchType arch =
CGM.getTarget().getTriple().getArch();
- // Most architectures require memory to fit within a single cache
- // line, so the alignment has to be at least the size of the access.
- // Otherwise we have to grab a lock.
- if (IvarAlignment < IvarSize && !hasUnalignedAtomics(arch)) {
-Kind = CopyStruct;
-return;
- }
-
// If the ivar's size exceeds the architecture's maximum atomic
// access size, we have to use CopyStruct.
if (IvarSize > getMaxAtomicAccessSize(CGM, arch)) {
diff --git a/clang/test/CodeGenObjC/objc_copyStruct.m
b/clang/test/CodeGenObjC/objc_copyStruct.m
index 7bbad866e2b1fb..8e52815a308abc 100644
--- a/clang/test/CodeGenObjC/objc_copyStruct.m
+++ b/clang/test/CodeGenObjC/objc_copyStruct.m
@@ -2,7 +2,7 @@
// RUN: %clang -target x86_64-apple-ios -fobjc-runtime=ios
-Wno-objc-root-class -S -o - -emit-llvm %s | FileCheck %s
struct S {
- float f, g;
+ double f, g;
};
@interface I
@@ -13,4 +13,3 @@ @implementation I
@end
// CHECK: declare {{.*}}void @objc_copyStruct(ptr, ptr, i64, i1, i1)
-
diff --git a/clang/test/CodeGenObjC/property-aggregate.m
b/clang/test/CodeGenObjC/property-aggregate.m
index f4211b6b62bd50..4c8c8893f920f4 100644
--- a/clang/test/CodeGenObjC/property-aggregate.m
+++ b/clang/test/CodeGenObjC/property-aggregate.m
@@ -1,13 +1,8 @@
// RUN: %clang_cc1 -triple x86_64-apple-darwin -emit-llvm %s -o - | FileCheck
%s
-// This structure's size is not a power of two, so the property does
-// not get native atomics, even though x86-64 can do unaligned atomics
-// with a lock prefix.
struct s3 { char c[3]; };
// This structure's size is, so it does, because it can.
-// FIXME: But we don't at the moment; the backend doesn't know how to generate
-// correct code.
struct s4 { char c[4]; };
@interface Test0
@@ -18,14 +13,8 @@ @implementation Test0
@synthesize s3, s4;
@end
-// CHECK: define internal i24 @"\01-[Test0 s3]"(
-// CHECK: call void @objc_copyStruct
-// CHECK: define internal void @"\01-[Test0 setS3:]"(
-// CHECK: call void @objc_copyStruct
-// CHECK: define internal i32 @"\01-[Test0 s4]"(
-// CHECK: call void @objc_copyStruct
-// CHECK: define internal void @"\01-[Test0 setS4:]"(
-// CHECK: call void @objc_copyStruct
+ NOTE: These prefixes are unused and the list is autogenerated. Do not add
tests below this line:
+// CHECK: {{.*}}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [ObjC] Defer to the LLVM backend for unaligned atomic load and stores (PR #79191)
https://github.com/AtariDreams updated
https://github.com/llvm/llvm-project/pull/79191
>From 22ddd0f489fa41521d8470b2bfe0288f77756d6f Mon Sep 17 00:00:00 2001
From: Rose <83477269+ataridre...@users.noreply.github.com>
Date: Tue, 23 Jan 2024 13:59:05 -0500
Subject: [PATCH] [ObjC] Defer to the LLVM backend for unaligned atomic load
and stores
LLVM can codegen correctly for atomics of any alignment in IR, on any
architecture (via using libcalls when necessary).
So, the ObjC code's hasUnalignedAtomics can be removed. We can use copyStruct
if the size is too big.
---
clang/lib/CodeGen/CGObjC.cpp| 17 -
clang/test/CodeGenObjC/objc_copyStruct.m| 3 +--
clang/test/CodeGenObjC/property-aggregate.m | 15 ++-
3 files changed, 3 insertions(+), 32 deletions(-)
diff --git a/clang/lib/CodeGen/CGObjC.cpp b/clang/lib/CodeGen/CGObjC.cpp
index 03fc0ec7ff54e1..353807fedf090a 100644
--- a/clang/lib/CodeGen/CGObjC.cpp
+++ b/clang/lib/CodeGen/CGObjC.cpp
@@ -842,15 +842,6 @@ static void emitStructGetterCall(CodeGenFunction ,
ObjCIvarDecl *ivar,
callee, ReturnValueSlot(), args);
}
-/// Determine whether the given architecture supports unaligned atomic
-/// accesses. They don't have to be fast, just faster than a function
-/// call and a mutex.
-static bool hasUnalignedAtomics(llvm::Triple::ArchType arch) {
- // FIXME: Allow unaligned atomic load/store on x86. (It is not
- // currently supported by the backend.)
- return false;
-}
-
/// Return the maximum size that permits atomic accesses for the given
/// architecture.
static CharUnits getMaxAtomicAccessSize(CodeGenModule ,
@@ -1019,14 +1010,6 @@ PropertyImplStrategy::PropertyImplStrategy(CodeGenModule
,
llvm::Triple::ArchType arch =
CGM.getTarget().getTriple().getArch();
- // Most architectures require memory to fit within a single cache
- // line, so the alignment has to be at least the size of the access.
- // Otherwise we have to grab a lock.
- if (IvarAlignment < IvarSize && !hasUnalignedAtomics(arch)) {
-Kind = CopyStruct;
-return;
- }
-
// If the ivar's size exceeds the architecture's maximum atomic
// access size, we have to use CopyStruct.
if (IvarSize > getMaxAtomicAccessSize(CGM, arch)) {
diff --git a/clang/test/CodeGenObjC/objc_copyStruct.m
b/clang/test/CodeGenObjC/objc_copyStruct.m
index 7bbad866e2b1fb..8e52815a308abc 100644
--- a/clang/test/CodeGenObjC/objc_copyStruct.m
+++ b/clang/test/CodeGenObjC/objc_copyStruct.m
@@ -2,7 +2,7 @@
// RUN: %clang -target x86_64-apple-ios -fobjc-runtime=ios
-Wno-objc-root-class -S -o - -emit-llvm %s | FileCheck %s
struct S {
- float f, g;
+ double f, g;
};
@interface I
@@ -13,4 +13,3 @@ @implementation I
@end
// CHECK: declare {{.*}}void @objc_copyStruct(ptr, ptr, i64, i1, i1)
-
diff --git a/clang/test/CodeGenObjC/property-aggregate.m
b/clang/test/CodeGenObjC/property-aggregate.m
index f4211b6b62bd50..4c8c8893f920f4 100644
--- a/clang/test/CodeGenObjC/property-aggregate.m
+++ b/clang/test/CodeGenObjC/property-aggregate.m
@@ -1,13 +1,8 @@
// RUN: %clang_cc1 -triple x86_64-apple-darwin -emit-llvm %s -o - | FileCheck
%s
-// This structure's size is not a power of two, so the property does
-// not get native atomics, even though x86-64 can do unaligned atomics
-// with a lock prefix.
struct s3 { char c[3]; };
// This structure's size is, so it does, because it can.
-// FIXME: But we don't at the moment; the backend doesn't know how to generate
-// correct code.
struct s4 { char c[4]; };
@interface Test0
@@ -18,14 +13,8 @@ @implementation Test0
@synthesize s3, s4;
@end
-// CHECK: define internal i24 @"\01-[Test0 s3]"(
-// CHECK: call void @objc_copyStruct
-// CHECK: define internal void @"\01-[Test0 setS3:]"(
-// CHECK: call void @objc_copyStruct
-// CHECK: define internal i32 @"\01-[Test0 s4]"(
-// CHECK: call void @objc_copyStruct
-// CHECK: define internal void @"\01-[Test0 setS4:]"(
-// CHECK: call void @objc_copyStruct
+ NOTE: These prefixes are unused and the list is autogenerated. Do not add
tests below this line:
+// CHECK: {{.*}}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [ObjC] Defer to the LLVM backend for unaligned atomic load and stores (PR #79191)
https://github.com/AtariDreams updated
https://github.com/llvm/llvm-project/pull/79191
>From 4c3de9cb4f027d88d254a01bbac81ac8eeafe67d Mon Sep 17 00:00:00 2001
From: Rose <83477269+ataridre...@users.noreply.github.com>
Date: Tue, 23 Jan 2024 13:59:05 -0500
Subject: [PATCH] [ObjC] Defer to the LLVM backend for unaligned atomic load
and stores
LLVM can codegen correctly for atomics of any alignment in IR, on any
architecture (via using libcalls when necessary).
So, the ObjC code's hasUnalignedAtomics can be removed. We can use copyStruct
if the size is too big.
---
clang/lib/CodeGen/CGObjC.cpp| 17 -
clang/test/CodeGenObjC/objc_copyStruct.m| 3 +--
clang/test/CodeGenObjC/property-aggregate.m | 15 ++-
3 files changed, 3 insertions(+), 32 deletions(-)
diff --git a/clang/lib/CodeGen/CGObjC.cpp b/clang/lib/CodeGen/CGObjC.cpp
index 03fc0ec7ff54e1..353807fedf090a 100644
--- a/clang/lib/CodeGen/CGObjC.cpp
+++ b/clang/lib/CodeGen/CGObjC.cpp
@@ -842,15 +842,6 @@ static void emitStructGetterCall(CodeGenFunction ,
ObjCIvarDecl *ivar,
callee, ReturnValueSlot(), args);
}
-/// Determine whether the given architecture supports unaligned atomic
-/// accesses. They don't have to be fast, just faster than a function
-/// call and a mutex.
-static bool hasUnalignedAtomics(llvm::Triple::ArchType arch) {
- // FIXME: Allow unaligned atomic load/store on x86. (It is not
- // currently supported by the backend.)
- return false;
-}
-
/// Return the maximum size that permits atomic accesses for the given
/// architecture.
static CharUnits getMaxAtomicAccessSize(CodeGenModule ,
@@ -1019,14 +1010,6 @@ PropertyImplStrategy::PropertyImplStrategy(CodeGenModule
,
llvm::Triple::ArchType arch =
CGM.getTarget().getTriple().getArch();
- // Most architectures require memory to fit within a single cache
- // line, so the alignment has to be at least the size of the access.
- // Otherwise we have to grab a lock.
- if (IvarAlignment < IvarSize && !hasUnalignedAtomics(arch)) {
-Kind = CopyStruct;
-return;
- }
-
// If the ivar's size exceeds the architecture's maximum atomic
// access size, we have to use CopyStruct.
if (IvarSize > getMaxAtomicAccessSize(CGM, arch)) {
diff --git a/clang/test/CodeGenObjC/objc_copyStruct.m
b/clang/test/CodeGenObjC/objc_copyStruct.m
index 7bbad866e2b1fb..8e52815a308abc 100644
--- a/clang/test/CodeGenObjC/objc_copyStruct.m
+++ b/clang/test/CodeGenObjC/objc_copyStruct.m
@@ -2,7 +2,7 @@
// RUN: %clang -target x86_64-apple-ios -fobjc-runtime=ios
-Wno-objc-root-class -S -o - -emit-llvm %s | FileCheck %s
struct S {
- float f, g;
+ double f, g;
};
@interface I
@@ -13,4 +13,3 @@ @implementation I
@end
// CHECK: declare {{.*}}void @objc_copyStruct(ptr, ptr, i64, i1, i1)
-
diff --git a/clang/test/CodeGenObjC/property-aggregate.m
b/clang/test/CodeGenObjC/property-aggregate.m
index f4211b6b62bd50..4c8c8893f920f4 100644
--- a/clang/test/CodeGenObjC/property-aggregate.m
+++ b/clang/test/CodeGenObjC/property-aggregate.m
@@ -1,13 +1,8 @@
// RUN: %clang_cc1 -triple x86_64-apple-darwin -emit-llvm %s -o - | FileCheck
%s
-// This structure's size is not a power of two, so the property does
-// not get native atomics, even though x86-64 can do unaligned atomics
-// with a lock prefix.
struct s3 { char c[3]; };
// This structure's size is, so it does, because it can.
-// FIXME: But we don't at the moment; the backend doesn't know how to generate
-// correct code.
struct s4 { char c[4]; };
@interface Test0
@@ -18,14 +13,8 @@ @implementation Test0
@synthesize s3, s4;
@end
-// CHECK: define internal i24 @"\01-[Test0 s3]"(
-// CHECK: call void @objc_copyStruct
-// CHECK: define internal void @"\01-[Test0 setS3:]"(
-// CHECK: call void @objc_copyStruct
-// CHECK: define internal i32 @"\01-[Test0 s4]"(
-// CHECK: call void @objc_copyStruct
-// CHECK: define internal void @"\01-[Test0 setS4:]"(
-// CHECK: call void @objc_copyStruct
+ NOTE: These prefixes are unused and the list is autogenerated. Do not add
tests below this line:
+// CHECK: {{.*}}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [ObjC] Defer to the LLVM backend for unaligned atomic load and stores (PR #79191)
jyknight wrote: Does this cause an ABI incompatibility? E.g. if we have a case where an existing object calls copyStruct on a given object (which presumably has its own internal mutex), and a newly compiled object file calls `__atomic_load` on the same object, implemented with its own internal mutex, the operations won't be atomic w.r.t. each-other. I don't know enough about ObjC codegen stuff to be able to say if there are mitigating factors that make this OK (e.g. if it's all within one TU?). Sidenote: please avoid rebase, amend, and force-pushing, because it makes it hard to review what's been changed -- instead, just keep adding more commits to your pull-request branch. https://github.com/llvm/llvm-project/pull/79191 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [ObjC] Defer to the LLVM backend for unaligned atomic load and stores (PR #79191)
https://github.com/AtariDreams updated
https://github.com/llvm/llvm-project/pull/79191
>From 2137c502467bbb14ef861a9920ca1a6a66c1a0ce Mon Sep 17 00:00:00 2001
From: Rose <83477269+ataridre...@users.noreply.github.com>
Date: Tue, 23 Jan 2024 13:59:05 -0500
Subject: [PATCH] [ObjC] Defer to the LLVM backend for unaligned atomic load
and stores
LLVM can codegen correctly for atomics of any alignment in IR, on any
architecture (via using libcalls when necessary).
So, the ObjC code's hasUnalignedAtomics can be removed. We can use copyStruct
if the size is too big.
---
clang/lib/CodeGen/CGObjC.cpp| 17 -
clang/test/CodeGenObjC/objc_copyStruct.m| 3 +--
clang/test/CodeGenObjC/property-aggregate.m | 15 ++-
3 files changed, 3 insertions(+), 32 deletions(-)
diff --git a/clang/lib/CodeGen/CGObjC.cpp b/clang/lib/CodeGen/CGObjC.cpp
index 03fc0ec7ff54e1..353807fedf090a 100644
--- a/clang/lib/CodeGen/CGObjC.cpp
+++ b/clang/lib/CodeGen/CGObjC.cpp
@@ -842,15 +842,6 @@ static void emitStructGetterCall(CodeGenFunction ,
ObjCIvarDecl *ivar,
callee, ReturnValueSlot(), args);
}
-/// Determine whether the given architecture supports unaligned atomic
-/// accesses. They don't have to be fast, just faster than a function
-/// call and a mutex.
-static bool hasUnalignedAtomics(llvm::Triple::ArchType arch) {
- // FIXME: Allow unaligned atomic load/store on x86. (It is not
- // currently supported by the backend.)
- return false;
-}
-
/// Return the maximum size that permits atomic accesses for the given
/// architecture.
static CharUnits getMaxAtomicAccessSize(CodeGenModule ,
@@ -1019,14 +1010,6 @@ PropertyImplStrategy::PropertyImplStrategy(CodeGenModule
,
llvm::Triple::ArchType arch =
CGM.getTarget().getTriple().getArch();
- // Most architectures require memory to fit within a single cache
- // line, so the alignment has to be at least the size of the access.
- // Otherwise we have to grab a lock.
- if (IvarAlignment < IvarSize && !hasUnalignedAtomics(arch)) {
-Kind = CopyStruct;
-return;
- }
-
// If the ivar's size exceeds the architecture's maximum atomic
// access size, we have to use CopyStruct.
if (IvarSize > getMaxAtomicAccessSize(CGM, arch)) {
diff --git a/clang/test/CodeGenObjC/objc_copyStruct.m
b/clang/test/CodeGenObjC/objc_copyStruct.m
index 7bbad866e2b1fb..8e52815a308abc 100644
--- a/clang/test/CodeGenObjC/objc_copyStruct.m
+++ b/clang/test/CodeGenObjC/objc_copyStruct.m
@@ -2,7 +2,7 @@
// RUN: %clang -target x86_64-apple-ios -fobjc-runtime=ios
-Wno-objc-root-class -S -o - -emit-llvm %s | FileCheck %s
struct S {
- float f, g;
+ double f, g;
};
@interface I
@@ -13,4 +13,3 @@ @implementation I
@end
// CHECK: declare {{.*}}void @objc_copyStruct(ptr, ptr, i64, i1, i1)
-
diff --git a/clang/test/CodeGenObjC/property-aggregate.m
b/clang/test/CodeGenObjC/property-aggregate.m
index f4211b6b62bd50..4c8c8893f920f4 100644
--- a/clang/test/CodeGenObjC/property-aggregate.m
+++ b/clang/test/CodeGenObjC/property-aggregate.m
@@ -1,13 +1,8 @@
// RUN: %clang_cc1 -triple x86_64-apple-darwin -emit-llvm %s -o - | FileCheck
%s
-// This structure's size is not a power of two, so the property does
-// not get native atomics, even though x86-64 can do unaligned atomics
-// with a lock prefix.
struct s3 { char c[3]; };
// This structure's size is, so it does, because it can.
-// FIXME: But we don't at the moment; the backend doesn't know how to generate
-// correct code.
struct s4 { char c[4]; };
@interface Test0
@@ -18,14 +13,8 @@ @implementation Test0
@synthesize s3, s4;
@end
-// CHECK: define internal i24 @"\01-[Test0 s3]"(
-// CHECK: call void @objc_copyStruct
-// CHECK: define internal void @"\01-[Test0 setS3:]"(
-// CHECK: call void @objc_copyStruct
-// CHECK: define internal i32 @"\01-[Test0 s4]"(
-// CHECK: call void @objc_copyStruct
-// CHECK: define internal void @"\01-[Test0 setS4:]"(
-// CHECK: call void @objc_copyStruct
+ NOTE: These prefixes are unused and the list is autogenerated. Do not add
tests below this line:
+// CHECK: {{.*}}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [ObjC] Defer to the LLVM backend for unaligned atomic load and stores (PR #79191)
https://github.com/AtariDreams updated
https://github.com/llvm/llvm-project/pull/79191
>From c34406a8fc9ecf0029fdf96883a4dce4e74e647a Mon Sep 17 00:00:00 2001
From: Rose <83477269+ataridre...@users.noreply.github.com>
Date: Tue, 23 Jan 2024 13:59:05 -0500
Subject: [PATCH] [ObjC] Defer to the LLVM backend for unaligned atomic load
and stores
LLVM can codegen correctly for atomics of any alignment in IR, on any
architecture (via using libcalls when necessary).
So, the ObjC code's hasUnalignedAtomics can be removed. We can use copyStruct
if the size is too big.
---
clang/lib/CodeGen/CGObjC.cpp| 17 -
clang/test/CodeGenObjC/objc_copyStruct.m| 3 +--
clang/test/CodeGenObjC/property-aggregate.m | 15 ++-
3 files changed, 3 insertions(+), 32 deletions(-)
diff --git a/clang/lib/CodeGen/CGObjC.cpp b/clang/lib/CodeGen/CGObjC.cpp
index 03fc0ec7ff54e1c..353807fedf090a8 100644
--- a/clang/lib/CodeGen/CGObjC.cpp
+++ b/clang/lib/CodeGen/CGObjC.cpp
@@ -842,15 +842,6 @@ static void emitStructGetterCall(CodeGenFunction ,
ObjCIvarDecl *ivar,
callee, ReturnValueSlot(), args);
}
-/// Determine whether the given architecture supports unaligned atomic
-/// accesses. They don't have to be fast, just faster than a function
-/// call and a mutex.
-static bool hasUnalignedAtomics(llvm::Triple::ArchType arch) {
- // FIXME: Allow unaligned atomic load/store on x86. (It is not
- // currently supported by the backend.)
- return false;
-}
-
/// Return the maximum size that permits atomic accesses for the given
/// architecture.
static CharUnits getMaxAtomicAccessSize(CodeGenModule ,
@@ -1019,14 +1010,6 @@ PropertyImplStrategy::PropertyImplStrategy(CodeGenModule
,
llvm::Triple::ArchType arch =
CGM.getTarget().getTriple().getArch();
- // Most architectures require memory to fit within a single cache
- // line, so the alignment has to be at least the size of the access.
- // Otherwise we have to grab a lock.
- if (IvarAlignment < IvarSize && !hasUnalignedAtomics(arch)) {
-Kind = CopyStruct;
-return;
- }
-
// If the ivar's size exceeds the architecture's maximum atomic
// access size, we have to use CopyStruct.
if (IvarSize > getMaxAtomicAccessSize(CGM, arch)) {
diff --git a/clang/test/CodeGenObjC/objc_copyStruct.m
b/clang/test/CodeGenObjC/objc_copyStruct.m
index 7bbad866e2b1fb2..8e52815a308abcb 100644
--- a/clang/test/CodeGenObjC/objc_copyStruct.m
+++ b/clang/test/CodeGenObjC/objc_copyStruct.m
@@ -2,7 +2,7 @@
// RUN: %clang -target x86_64-apple-ios -fobjc-runtime=ios
-Wno-objc-root-class -S -o - -emit-llvm %s | FileCheck %s
struct S {
- float f, g;
+ double f, g;
};
@interface I
@@ -13,4 +13,3 @@ @implementation I
@end
// CHECK: declare {{.*}}void @objc_copyStruct(ptr, ptr, i64, i1, i1)
-
diff --git a/clang/test/CodeGenObjC/property-aggregate.m
b/clang/test/CodeGenObjC/property-aggregate.m
index f4211b6b62bd503..4c8c8893f920f4a 100644
--- a/clang/test/CodeGenObjC/property-aggregate.m
+++ b/clang/test/CodeGenObjC/property-aggregate.m
@@ -1,13 +1,8 @@
// RUN: %clang_cc1 -triple x86_64-apple-darwin -emit-llvm %s -o - | FileCheck
%s
-// This structure's size is not a power of two, so the property does
-// not get native atomics, even though x86-64 can do unaligned atomics
-// with a lock prefix.
struct s3 { char c[3]; };
// This structure's size is, so it does, because it can.
-// FIXME: But we don't at the moment; the backend doesn't know how to generate
-// correct code.
struct s4 { char c[4]; };
@interface Test0
@@ -18,14 +13,8 @@ @implementation Test0
@synthesize s3, s4;
@end
-// CHECK: define internal i24 @"\01-[Test0 s3]"(
-// CHECK: call void @objc_copyStruct
-// CHECK: define internal void @"\01-[Test0 setS3:]"(
-// CHECK: call void @objc_copyStruct
-// CHECK: define internal i32 @"\01-[Test0 s4]"(
-// CHECK: call void @objc_copyStruct
-// CHECK: define internal void @"\01-[Test0 setS4:]"(
-// CHECK: call void @objc_copyStruct
+ NOTE: These prefixes are unused and the list is autogenerated. Do not add
tests below this line:
+// CHECK: {{.*}}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [ObjC] Defer to the LLVM backend for unaligned atomic load and stores (PR #79191)
https://github.com/AtariDreams edited https://github.com/llvm/llvm-project/pull/79191 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [ObjC] Defer to the LLVM backend for unaligned atomic load and stores (PR #79191)
https://github.com/AtariDreams edited https://github.com/llvm/llvm-project/pull/79191 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
