This is the mail archive of the
mailing list for the GCC project.
Re: volatile access optimization (C++ / x86_64)
- From: Andrew Haley <aph at redhat dot com>
- To: Matt Godbolt <matt at godbolt dot org>, GCC Development <gcc at gcc dot gnu dot org>
- Date: Fri, 26 Dec 2014 22:26:35 +0000
- 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>
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.