__sync_lock_test_and_set on ARM

[Phil Endecott]

David Daney wrote:
> Phil Endecott wrote:
>> David Daney wrote:
>>> There is nothing that says that __sync_compar_and_swap() cannot expand 
>>> to a libcall.
>> 
>>> Ideally a GCC user would not have to write target specific assembly 
>>> for this.
>> 
>> If I just had one algorithm for my locking problem then, yes, that would 
>> be fine.  But as it happens I have two algorithms, one of which uses 
>> atomic compare-and-set and one of which uses atomic swap.  I want to use 
>> whichever maps best to the target architecture.  So I need to be able to 
>> distinguish between a builtin that expands to a couple of inline 
>> instructions and a builtin that expands to a library call.
>> 
>> If someone would like to add OS-specific builtins for the other atomic 
>> operations, that's fine, but please do something so that I can identify 
>> that they involve library or kernel calls (e.g. #define 
>> __SYNC_COMPARE_AND_SET_n=ASM vs. #define 
>> __SYNC_COMPARE_AND_SET_n=LIBRARY.)  But that looks like a lot more work 
>> than just adding one builtin for SWP, which is all that I need.
>
> In the purely hypothetical situation that this were implemented, GCC 
> would do the right thing based on the -march=??? parameter.  The user's 
> code would not need to know that a 'swp' or a kernel system call was 
> being made

..unless it cared about performance.  I do care about performance, 
which is why I have two different algorithms, one for architectures 
with compare-and-swap and one for architectures with swap.  So I would 
like to know how the builtin is implemented.


Phil.