[patch?] Linux ARM atomics

[John McCall]

On Apr 15, 2013, at 11:12 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
>> The use of a library function is ABI and therefore a natural frontend responsibility.
>> Among other things:
>>  - the atomic library functions are not guaranteed to be atomic w.r.t. the processor's
>>    primitive atomics and
>>  - different targets may require us to use a different set of atomic library functions
>>    or provide slightly different semantics to them.
>> 
>> So it makes sense for the backend to require that the frontend just not emit
>> illegal primitive atomic operations.
> 
> I see. I was reading http://gcc.gnu.org/wiki/Atomic/GCCMM/LIbrary and
> got the impression that the atomic operations had to be implemented in
> a shared library so that new atomic support in a processor could be
> utilized. I guess the document is out of date and the atomic
> operations that are available in portable code are just locked when an
> ABI for an architecture is defined, correct?

I would say this:

1. The target ABI defines the correct size and alignment for _Atomic objects.
This is locked eternally and does not vary by things like target library versions;
any change to this requires an ABI variant.

2. The target atomics library defines the correct access mechanism(s) for
atomic objects of a given size and minimum alignment.

3. A particular version of an atomics library may choose to guarantee a certain
implementation for atomic accesses when running on a certain architecture.
This decision may not be revoked in a later version of that library.

4. A compiler may therefore inline the implementation of an atomic access
if it knows that it is generating code which will run on an architecture X and
with an atomics library that guarantees the implementation of that access on X.

For example, suppose that a new x86 chip adds native 57-bit atomic
operations, and libc v47.0.21 promises to use them.  The compiler can now
inline 57-bit atomic accesses *if* (1) it's guaranteed that the generated code
will only run on the new chip (or later) and (2) it's guaranteed that the generated
code will only be deployed to systems with libc v47.0.21 or newer.

Actually acquiring this kind of OS deployment target information is an exercise
for the reader. :)  But yeah, if you don't know what OS you're targeting, CPU
details aren't good enough.

Of course, the implementation can be inlined solely based on target arch
if the compiler can prove (or is told somehow) that it doesn't need to worry
about interoperation.

> If that is the case,  the comment
> 
> // FIXME: Set MaxAtomicInlineWidth if we have the feature v6e
> 
> is incorrect, no? The correct fix for this case is to set
> MaxAtomicInlineWidth when using the hard float ABI variant.

The hard-float ABI variant would probably be a sufficient condition.
The v6e feature alone wouldn't be;  you'd also need to know the deployment
target.

John.