__sync_lock_test_and_set on ARM

David Daney ddaney@avtrex.com
Thu Sep 13 17:23:00 GMT 2007


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, so there would be no reason to test for that.

David Daney



More information about the Gcc-help mailing list