This is the mail archive of the
mailing list for the GCC project.
Re: volatile access optimization (C++ / x86_64)
- From: Torvald Riegel <triegel at redhat dot com>
- To: Andrew Haley <aph at redhat dot com>
- Cc: Matt Godbolt <matt at godbolt dot org>, GCC Development <gcc at gcc dot gnu dot org>
- Date: Tue, 30 Dec 2014 12:05:01 +0100
- Subject: Re: volatile access optimization (C++ / x86_64)
- Authentication-results: sourceware.org; auth=none
- References: <CAFWXXN3quEdSnaoWuPcQn2k-F99Yaw+6=NqgFgcu9ABpv5ZD3Q at mail dot gmail dot com> <549DE09B dot 8060502 at redhat dot com>
On Fri, 2014-12-26 at 22:26 +0000, Andrew Haley wrote:
> On 26/12/14 20:32, Matt Godbolt wrote:
> > I'm investigating ways to have single-threaded writers write to memory
> > areas which are then (very infrequently) read from another thread for
> > monitoring purposes. Things like "number of units of work done".
> > I initially modeled this with relaxed atomic operations. This
> > generates a "lock xadd" style instruction, as I can't convey that
> > there are no other writers.
> > As best I can tell, there's no memory order I can use to explain my
> > usage characteristics.
> > Giving up on the atomics, I tried volatiles.
> > These are less than ideal as their power is less expressive, but in my
> > instance I am not trying to fight the ISA's reordering; just prevent
> > the compiler from eliding updates to my shared metrics.
> > GCC's code generation uses a "load; add; store" for volatiles, instead
> > of a single "add 1, [metric]".
> This is correct.
> > http://goo.gl/dVzRSq has the example (which is also at the bottom of my email).
> > Is there a reason why (in principal) the volatile increment can't be
> > made into a single add? Clang and ICC both emit the same code for the
> > volatile and non-volatile case.
> Yes. Volatiles use the "as if" rule, where every memory access is as
> written. a volatile increment is defined as a load, an increment, and
> a store. If you want single atomic increment, atomics are what you
> should use. If you want an increment to be written to memory, use a
> store barrier after the increment.
I agree with Andrew. My understanding of volatile is that the generated
code must do exactly what the abstract machine would do.
One can use volatiles for synchronization if one is also manually adding
HW barriers and potentially compiler barriers (depending on whether you
need to mix volatile and non-volatile) -- but volatiles really aim at a
different use case than atomics.
For the single-writer shared-counter case, a load and a store operation
with memory_order_relaxed seem to be right approach.