This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: volatile access optimization (C++ / x86_64)

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.

> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]