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 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
