On Tue, May 30, 2017 at 10:02 AM, Jonathan Wakely <jwakely.gcc@xxxxxxxxx> wrote:
> On 30 May 2017 at 14:57, Andrew Haley wrote:
>> On 30/05/17 11:28, Jonathan Wakely wrote:
>>> On 28 May 2017 at 12:15, Toebs Douglass wrote:
>>>> I would like to write a little about the new libatomic mechanism for
>>>> What I see however is that there is a way for me to avoid these costs
>>>> and return to the simple situation. My code has an abstraction layer,
>>>> and I can implement inline assembly for double-word CAS on 64-bit
>>>> platforms and use that instead of __atomic and __sync.
>>>
>>> On x86_64 can't you just use __sync_val_compare_and_swap with -mcx16?
>>>
>>> Since GCC 4.6 this always emits cmpxchg16b when compiled with -mcx16:
>>>
>>> int main()
>>> {
>>> __int128 i = 0;
>>> __sync_val_compare_and_swap(&i, 0, 1);
>>> }
>>>
>>> That still works with GCC 7.
>>
>> I just built GCC from trunk, and this gives me:
>>
>> mustang-b0:~ $ /scratch/gcc/trunk/install/bin/gcc zzz.c
>> /tmp/ccmc3Y73.o: In function `main':
>> zzz.c:(.text+0x20): undefined reference to `__sync_val_compare_and_swap_16'
>> collect2: error: ld returned 1 exit status
>>
>> I can't figure out where __sync_val_compare_and_swap_16 should be
>> defined. It's not in libatomic or libc or libgcc.
>
> But if you compile with -mcx16 then it should use cmpxchg16b instead
> of a library call.
>
> That only works for x86_64 (like the -mcx16 option itself). I don't
> know how to guarantee no library call for aarch64.
Is there a way to guarantee not calling the library for all of the
__atomic* builtins with only passing an -march=X that supports the
instructions? I switched everything once already from __sync to
__atomic; I'd hate to switch back.
