Re: __sync_lock_test_and_set on ARM
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
[Index of Archives]
[Linux C Programming]
[Linux Kernel]
[eCos]
[Fedora Development]
[Fedora Announce]
[Autoconf]
[The DWARVES Debugging Tools]
[Yosemite Campsites]
[Yosemite News]
[Linux GCC]