================
@@ -133,19 +133,24 @@ void ARMTargetInfo::setArchInfo(llvm::ARM::ArchKind Kind)
{
}
void ARMTargetInfo::setAtomic() {
- // when triple does not specify a sub arch,
- // then we are not using inline atomics
- bool ShouldUseInlineAtomic =
- (ArchISA == llvm::ARM::ISAKind::ARM && ArchVersion >= 6) ||
- (ArchISA == llvm::ARM::ISAKind::THUMB && ArchVersion >= 7);
- // Cortex M does not support 8 byte atomics, while general Thumb2 does.
if (ArchProfile == llvm::ARM::ProfileKind::M) {
+ // M-class only ever supports 32-bit atomics. Cortex-M0 doesn't have
+ // any atomics.
MaxAtomicPromoteWidth = 32;
- if (ShouldUseInlineAtomic)
+ if (ArchVersion >= 7)
MaxAtomicInlineWidth = 32;
} else {
+ // A-class targets have up to 64-bit atomics.
+ //
+ // On Linux, 64-bit atomics are always available through kernel helpers
+ // (which are lock-free). Otherwise, atomics are available on v6 or later.
+ //
+ // (Thumb doesn't matter; for Thumbv6, we just use a library call which
+ // switches out of Thumb mode.)
+ //
+ // This should match setMaxAtomicSizeInBitsSupported() in the backend.
MaxAtomicPromoteWidth = 64;
- if (ShouldUseInlineAtomic)
+ if (getTriple().getOS() == llvm::Triple::Linux || ArchVersion >= 6)
----------------
statham-arm wrote:
I'm confused by the word `Inline` in the identifier. Surely in the case where
Linux does the atomic operation by calling a kernel helper function, the one
thing it isn't is _inline!_
But I see that `CodeGenFunction::EmitAtomicExpr` really seems to be treating it
as "maximum _efficient_ atomic size", in that it emits a warning for anything
bigger saying that it might be slow.
https://github.com/llvm/llvm-project/pull/151404
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
