This is the mail archive of the
mailing list for the GCC project.
Re: GCC libatomic ABI specification draft
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: triegel at redhat dot com (Torvald Riegel)
- Cc: paubert at iram dot es (Gabriel Paubert), bin dot x dot fan at oracle dot com (Bin Fan@Work), szabolcs dot nagy at arm dot com (Szabolcs Nagy), gcc at gcc dot gnu dot org (gcc at gcc dot gnu dot org), nd at arm dot com
- Date: Tue, 20 Dec 2016 14:26:58 +0100 (CET)
- Subject: Re: GCC libatomic ABI specification draft
- Authentication-results: sourceware.org; auth=none
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.
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain