Re: [boost] [atomic] Help understanding consume order

Subject: Re: [boost] [atomic] Help understanding consume order
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2014-06-02 13:11:27

On Monday 02 June 2014 12:42:04 Giovanni Piero Deretta wrote:
> On Sun, Jun 1, 2014 at 11:58 AM, Andrey Semashev <andrey.semashev_at_[hidden]>
> wrote:
> 
> ARM and many other RMO architectures (like PPC and unlike Alpha), guarantee
> that a load and the load it depends on won't be reordered, so, together
> with the release operation on the writer side, the load_consume guarantees
> the visibility of the string body.

Ok, so basically, on ARM and PPC consume operation should be equivalent to 
relaxed + a compiler barrier to prevent possible code reordering, am I right?

> The exact definition of load dependency (basically the address of the
> dependent load is computed as a function of the value returned by the
> depending load) is defined at the instruction level and is quite tricky to
> recover at the high level C++ language. C++11 tried to do it, but according
> to a few the current working is both very hard to implement and both not
> strong enough and too strict in some cases.
>
> In the meantime GCC (and a few other compilers) punts on load_consume and
> simply promotes it to load_acquire.

Yes, I noticed that. MSVC seems to follow the same route as well.

> > I guess, that's the ultimate question: how should consume ordering be
> > handled
> > on conventional architectures.
> 
> That's hard to do without compiler help unfortunately. Compilers have
> started doing some quite aggressive optimisations (like value speculation
> and PGO) that can break loads dependencies. The linux kernel for example
> gets by by explicitly disabling those optimisations, not doing PGO and
> targeting a specific compiler.

I hope, speculative loads and stores can be prevented with compiler barriers. 
But it looks like PGO/IPO/LTO may ruin the code involving this memory 
ordering. I suppose, even if I put a compiler barrier (which in case of gcc is 
an empty asm statement with memory in the clobber list) it will not be in 
effect during the optimization phase?

> See n2664 and the recent epic thread on gcc-dev.

Is it this thread?

https://gcc.gnu.org/ml/gcc/2014-02/msg00052.html

I'm reading it now, very interesting, thank you for the tip.