Re: Is WRITE_ONCE() enough to prevent invention of stores?

["Paul E. McKenney" <paulmck@linux.vnet.ibm.com>]

On Sat, Sep 16, 2017 at 08:01:45PM +0900, Akira Yokosawa wrote:
> Hi Paul,
> 
> I'm a bit disturbed by the description in Section 14.3.1 "Memory-Reference
> Restrictions" quoted below:
> 
> > Oddly enough, the compiler is within its rights to use a variable
> > as temporary storage just before a store to that variable, thus
> > inventing stores to that variable.
> > Fortunately, most compilers avoid this sort of thing, at least outside
> > of stack variables.
> > Nevertheless, using WRITE_ONCE() (or declaring the variable
> > volatile) should prevent this sort of thing.
> > But take care: If you have a translation unit that uses that variable,
> > and never makes a volatile access to it, the compiler has no way of
> > knowing that it needs to be careful.
> 
> I'm wondering if using WRITE_ONCE() in a translation unit is really
> enough to prevent invention of stores.
> 
> Accessing via a volatile-cast pointer guarantees the access is not
> optimized out (and hopefully the referenced value is respected).
> 
> But I suspect that it has any effect in preventing invention of extra
> loads/stores.
> 
> Isn't declaring the variable volatile necessary for the guarantee?
> 
> In practice, as is described in the above quote: "Fortunately, most
> compilers avoid this sort of thing, at least outside of stack variables",
> we can assume non-volatile shared variables are not spilled out to
> the variables themselves as far as GCC/LLVM is concerned.
> But this is compiler dependent, I suppose.

I suspect that it will turn out to be impossible for the compiler to
actually invent these stores in the general case.  For example, it might
be that there is some lock held or other synchronization mechanism unknown
to the compiler that prevents this behavior.  But I haven't fully worked
this out yet.

But I do know that if you just do plain stores, the compiler is fully
within its rights to invent stores preceding any given plain store.

							Thanx, Paul