Re: __sync_lock_test_and_set on ARM

["Phil Endecott" <spam_from_gcc_help_2@xxxxxxxxxxxx>]

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.