This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC libatomic ABI specification draft
- From: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: Ulrich Weigand <uweigand at de dot ibm dot com>, Torvald Riegel <triegel at redhat dot com>
- Cc: <nd at arm dot com>, Gabriel Paubert <paubert at iram dot es>, "Bin Fan@Work" <bin dot x dot fan at oracle dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Tue, 20 Dec 2016 13:58:27 +0000
- Subject: Re: GCC libatomic ABI specification draft
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=none (sender IP is ) smtp.mailfrom=Szabolcs dot Nagy at arm dot com;
- Nodisclaimer: True
- References: <20161220132658.30E8E103E6E@oc8523832656.ibm.com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
On 20/12/16 13:26, Ulrich Weigand wrote:
> Torvald Riegel wrote:
>> On Fri, 2016-12-02 at 12:13 +0100, Gabriel Paubert wrote:
>>> On Thu, Dec 01, 2016 at 11:13:37AM -0800, Bin Fan at Work wrote:
>>>> Thanks for the comment. Yes, the ABI requires libatomic must query the hardware. This is
>>>> necessary if we want the compiler to generate inlined code for 16-byte atomics. Note that
>>>> this particular issue only affects x86.
>>>
>>> Why? Power (at least recent ones) has 128 bit atomic instructions
>>> (lqarx/stqcx.) and Z has 128 bit compare and swap.
>>
>> That's not the only factor affecting whether cmpxchg16b or such is used
>> for atomics. If the HW just offers a wide CAS but no wide atomic load,
>> then even an atomic load is not truly just a load, which breaks (1)
>> atomic loads on read-only mapped memory and (2) volatile atomic loads
>> (unless we claim that an idempotent store is like a load, which is quite
>> a stretch for volatile I think).
>
> I may have missed the context of the discussion, but just on the
> specific ISA question here: both Power and z not only have the
> 16-byte CAS (or load-and-reserve/store-conditional), but they also both
> have specific 16-byte atomic load and store instructions (lpq/stpq
> on z, lq/stq on Power).
>
> Those are available on any system supporting z/Architecture (z900 and up),
> and on any Power system supporting the V2.07 ISA (POWER8 and up). GCC
> does in fact use those instructions to implement atomic operations on
> 16-byte data types on those machines.
that's a bug.
at least i don't see how gcc makes sure the libatomic
calls can interoperate with inlined atomics.