[PATCH] ARM: allow inline atomics on Cortex M

[Jonathan Roelofs]

On 6/16/14, 4:20 PM, Phoebe Buckheister wrote:
> On Mon, 16 Jun 2014 15:36:00 -0600, Jonathan Roelofs wrote:
>>> 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.
>
> I'm totally confused about this now. Always enabling atomics on Windows
> seems fine, if that'll only run on hardware that has atomic
> instructions anyway. But if we forced atomics off for anything that
> wasn't Linux, a BSD or Bitrig anyway, and then required the Arch
> version to match - really, why check for the OS at all? If we're not
> going to emit anything that would call into the OS ourselves, the check
> seems unnecessarily restrictive. If we hard-enable inline atomics for
> Linux and the others, we'll not emit libcalls for atomics on those at
> all.
>
> I really have no idea to fix this now. Could you clear up my
> confusion?

The requirement that the OS be (Linux || FreeBSD || NetBSD || Bitrig) is only 
there when we can't generate an instruction sequence to handle the atomic, and 
therefore we have to rely on __sync_* (and therefore the kernel because of the 
implementation of those builtins on those platforms) to handle it for us.

I'm not sure about the windows case.

So unless *I'm* really misunderstanding (which is quite possible :] ), the set 
of checks (in pseudocode) should roughly be:

    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;

>
>> Jon

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