This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC libatomic ABI specification draft
- From: Torvald Riegel <triegel at redhat dot com>
- To: Gabriel Paubert <paubert at iram dot es>
- Cc: Bin Fan at Work <bin dot x dot fan at oracle dot com>, Szabolcs Nagy <szabolcs dot nagy at arm dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, nd at arm dot com
- Date: Mon, 19 Dec 2016 17:32:52 +0100
- Subject: Re: GCC libatomic ABI specification draft
- Authentication-results: sourceware.org; auth=none
- References: <db02a1bf-0eee-15a5-0e1f-f8124021e45d@redhat.com> <a73c2aa3-31d4-05a6-19e6-f9efa98fbfe3@redhat.com> <8764e547-1dd2-3ebd-2723-6568b4b54092@oracle.com> <ac2d60ed-a659-f018-1f11-63fa8f5847f5@oracle.com> <1470412312.14544.4.camel@localhost.localdomain> <4a182edd-41a8-4ad9-444a-bf0af567ae98@oracle.com> <8317ec9d-41ad-d806-9144-eac2984cdd38@oracle.com> <c2d90b1a-0b0e-0460-d28f-a02ad15f5ab3@oracle.com> <583D627E.60103@arm.com> <1B989D8B-7AFE-401E-90FD-A683AC9E81EB@oracle.com> <20161202111324.GA20797@visitor2.iram.es>
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:
> > Hi Szabolcs,
> >
> > > On Nov 29, 2016, at 3:11 AM, Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
> > >
> > > On 17/11/16 20:12, Bin Fan wrote:
> > >>
> > >> Although this ABI specification specifies that 16-byte properly aligned atomics are inlineable on platforms
> > >> supporting cmpxchg16b, we document the caveats here for further discussion. If we decide to change the
> > >> inlineable attribute for those atomics, then this ABI, the compiler and the runtime implementation should be
> > >> updated together at the same time.
> > >>
> > >>
> > >> The compiler and runtime need to check the availability of cmpxchg16b to implement this ABI specification.
> > >> Here is how it would work: The compiler can get the information either from the compiler flags or by
> > >> inquiring the hardware capabilities. When the information is not available, the compiler should assume that
> > >> cmpxchg16b instruction is not supported. The runtime library implementation can also query the hardware
> > >> compatibility and choose the implementation at runtime. Assuming the user provides correct compiler options
> > >
> > > with this abi the runtime implementation *must* query the hardware
> > > (because there might be inlined cmpxchg16b in use in another module
> > > on a hardware that supports it and the runtime must be able to sync
> > > with it).
> >
> > 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).