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.
Thanks, Akira
--
To unsubscribe from this list: send the line "unsubscribe perfbook" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
