[PATCH] ARM: allow inline atomics on Cortex M

[Jonathan Roelofs]

On 6/16/14, 3:00 PM, Phoebe Buckheister wrote:
> Current code to determine availability of atomics seems a bit
> incorrect, or at least weird.
>
> I don't quite understand why clang looks at the OS specified in the
> triple, as availability of atomic instructions doesn't depend on the
> OS; it only depends on the arch version and the execution mode. Atomics
> are there in ARM mode on v6 and later, and in Thumb mode on v7 and later
> (but no ldrexd/strexd in the M profile).
Clang is looking at the OS because these OSes support calling a kernel provided 
cmpxchg, which is what you need to make the __sync_* builtins work on pre v6 
hardware (and this is how they are implemented in libgcc).

Given that, I think that this check and comment:

```
-    // On linux, binaries targeting old cpus call functions in libgcc to
-    // perform atomic operations. The implementation in libgcc then calls into
-    // the kernel which on armv6 and newer uses ldrex and strex. The net result
-    // is that if we assume the kernel is at least as recent as the hardware,
-    // it is safe to use atomic instructions on armv6 and newer.
-    if (!T.isOSLinux() &&
-        T.getOS() != llvm::Triple::FreeBSD &&
-        T.getOS() != llvm::Triple::NetBSD &&
-        T.getOS() != llvm::Triple::Bitrig)
-      return false;
```

ought to really be placed as a fallback if the HW is older than v6.


Cheers,

Jon

>
> This patch is an attempt to rectify the situation: check only the arch
> version - correctly, as thumbv7em fails the old check - and allow
> atomics up to 32 bits on the ARMv7 M profiles.
>
> If the OS check has a reason I missed, I'll add it back - but bare
> metal wants atomics too ...
>
>
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>

-- 
Jon Roelofs
jonathan at codesourcery.com
CodeSourcery / Mentor Embedded