[PATCH] ARM: allow inline atomics on Cortex M

[Phoebe Buckheister]

On Tue, 17 Jun 2014 09:29:42 -0600, Jonathan Roelofs wrote:
> 
> 
> On 6/17/14, 2:11 AM, Renato Golin wrote:
> > On 16 June 2014 23:59, Jonathan Roelofs <jonathan at codesourcery.com>
> > wrote:
> >>     if ( windows ) return true;
> >>     else if ( arch >= v6 ) {
> >>       version = whatever;
> >>     } else if ( !linux && !freebsd && !netbsd && !bitrig ) {
> >>       return false;
> >>     }
> >>
> >>     if ( Profile == "M" && MaxAtomicInlineWidth) {
> >>        MaxAtomicPromoteWidth = 32;
> >>        MaxAtomicInlineWidth = 32;
> >>     }
> >>     return true;
> >
> > This sequence sounds correct to me, too.
> After having slept on this, I don't think I was correct with that
> snippet, and here is why:
> 
> In order for the atomic inlining to be safe here, we must satisfy
> two conditions:
>    1)  The architecture supports ldrex/strex
>    2)  The platform provided builtins (read: libgcc), if any
>        (read: baremetal), implements them using the same primitives
>        (i.e. not a swp-based kernel-provided cmpxchg, or otherwise)
> 
> In the case of baremetal, we really only care about #1.  But when
> there is a platform involved, we have to be more careful that we
> do using the same primitives that the libcalls are implemented
> with, being conservative when we don't know that it is safe... That
> means emitting libcalls both when we know we have to, and when
> we're not sure.
> 
> The original code before Phoebe's patch almost gets that right, but
> is a little too conservative in the baremetal cases on both M-class
> cpus and non M-class cpus.
> 
> Attached is what I now think the patch ought to be.

That works fine as well. I'm all for your changed version.

> Cheers,
> Jon
> 
> P.S. Phoebe, sorry for adding to the confusion :)
> >
> > cheers,
> > -renato
> >
> 
> -- 
> Jon Roelofs
> jonathan at codesourcery.com
> CodeSourcery / Mentor Embedded