This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: __sync_lock_test_and_set on ARM


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 Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]