On 6/16/14, 3:31 PM, Phoebe Buckheister wrote:
Hi,
On Mon, 16 Jun 2014 15:21:59 -0600, Jonathan Roelofs wrote:
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:
[…]
ought to really be placed as a fallback if the HW is older than v6.
Thanks, I'll put it back. I had assumed that in those cases, clang
would just always generate inline atomics and let LLVM fix it up if the
actual hardware doesn't support it.
I agree with your first suspicions though... this chunk of code isn't in exactly
the right spot, and so isn't checking the right thing.
Jon
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
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
--
Jon Roelofs
[email protected]
CodeSourcery / Mentor Embedded
--
Jon Roelofs
[email protected]
CodeSourcery / Mentor Embedded
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
