Date: Thu, 19 Apr 2018 15:25:19 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: [PATCH 2/2] arm: enable a_ll and a_sc helper functions when building for ARMv6T2 On Thu, Apr 19, 2018 at 12:14:51PM -0700, Andre McCurdy wrote: > On Thu, Apr 19, 2018 at 9:38 AM, Rich Felker <dalias@...c.org> wrote: > > On Wed, Apr 18, 2018 at 06:51:44PM -0700, Andre McCurdy wrote: > >> ARMv6 cores with support for Thumb2 can take advantage of the "ldrex" > >> and "strex" based implementations of a_ll and a_sc. > >> --- > >> arch/arm/atomic_arch.h | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/arch/arm/atomic_arch.h b/arch/arm/atomic_arch.h > >> index 5ff1be1..62458b4 100644 > >> --- a/arch/arm/atomic_arch.h > >> +++ b/arch/arm/atomic_arch.h > >> @@ -8,7 +8,7 @@ extern uintptr_t __attribute__((__visibility__("hidden"))) > >> __a_cas_ptr, __a_barrier_ptr; > >> > >> #if ((__ARM_ARCH_6__ || __ARM_ARCH_6K__ || __ARM_ARCH_6KZ__ || __ARM_ARCH_6ZK__) && !__thumb__) \ > >> - || __ARM_ARCH_7A__ || __ARM_ARCH_7R__ || __ARM_ARCH >= 7 > >> + || __ARM_ARCH_6T2__ || __ARM_ARCH_7A__ || __ARM_ARCH_7R__ || __ARM_ARCH >= 7 > >> > >> #define a_ll a_ll > >> static inline int a_ll(volatile int *p) > > > > I'm merging this along with the others, but there is some concern that > > our use of a_ll/a_sc might not actually be valid on most or all of the > > archs we currently use it on. Depending on how this turns out it might > > all be removed at some later time. > > That sound ominous. What's the concern? Originally ARM didn't document it, but reportedly it's now documented somewhere that the ll and sc operations have certain strong conditions on how they're used. RISC-V's and maybe other archs' also have similar conditions. They're something along the lines of (from my memory): - no intervening loads or stores between ll and sc - limit on number of instructions between ll and sc - no jumps or branches between ll and sc and there is no way to guarantee these kinds of conditions when the compiler is free to move the ll and sc asm blocks independently. >From a practical standpoint, it looks like the conditions are overly conservative and designed to allow cpu implementations with very bad cache designs (direct-mapped, small, etc.) but they may turn out to be relevant so we need to evaluate if we need to care about this... Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.