[clang] dd8afce - [Clang] Remove dead code related to atomics (NFC) (#216614)

[via cfe-commits]

Author: AZero13
Date: 2026-08-22T18:43:25-07:00
New Revision: dd8afce5797a6c638840ce17a9a5c6d88ae60d03

URL: https://github.com/llvm/llvm-project/commit/dd8afce5797a6c638840ce17a9a5c6d88ae60d03
DIFF: https://github.com/llvm/llvm-project/commit/dd8afce5797a6c638840ce17a9a5c6d88ae60d03.diff

LOG: [Clang] Remove dead code related to atomics (NFC) (#216614)

This PR cleans up dead code in `CGObjC.cpp` related to unaligned
atomics.

Because the synchronization strategy (native vs. objc_copyStruct) is
baked into the ABI for compiled frameworks, it can essentially never be
changed for existing architectures like x86 without breaking backwards
compatibility.

Added: 
    

Modified: 
    clang/lib/CodeGen/CGObjC.cpp
    clang/test/CodeGenObjC/property-aggregate.m

Removed: 
    


################################################################################
diff  --git a/clang/lib/CodeGen/CGObjC.cpp b/clang/lib/CodeGen/CGObjC.cpp
index c724a063bafe8..b9cbf593fb1c4 100644
--- a/clang/lib/CodeGen/CGObjC.cpp
+++ b/clang/lib/CodeGen/CGObjC.cpp
@@ -869,19 +869,9 @@ static void emitStructGetterCall(CodeGenFunction &CGF, 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 &CGM,
-                                        llvm::Triple::ArchType arch) {
+static CharUnits getMaxAtomicAccessSize(CodeGenModule &CGM) {
   // ARM has 8-byte atomic accesses, but it's not clear whether we
   // want to rely on them here.
 
@@ -1047,20 +1037,17 @@ PropertyImplStrategy::PropertyImplStrategy(CodeGenModule &CGM,
     return;
   }
 
-  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)) {
+  if (IvarAlignment < IvarSize) {
     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)) {
+  if (IvarSize > getMaxAtomicAccessSize(CGM)) {
     Kind = CopyStruct;
     return;
   }

diff  --git a/clang/test/CodeGenObjC/property-aggregate.m b/clang/test/CodeGenObjC/property-aggregate.m
index f4211b6b62bd5..2bb00ca560ce5 100644
--- a/clang/test/CodeGenObjC/property-aggregate.m
+++ b/clang/test/CodeGenObjC/property-aggregate.m
@@ -1,13 +1,10 @@
 // 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.
+// not get native atomics.
 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.
+// This structure's size is a power of two, but its alignment is 1.
 struct s4 { char c[4]; };
 
 @interface Test0