On Thursday, 15 November 2012 at 22:58:53 UTC, Andrei
Alexandrescu wrote:
On 11/15/12 2:18 PM, David Nadlinger wrote:
On Thursday, 15 November 2012 at 16:43:14 UTC, Sean Kelly
wrote:
On Nov 15, 2012, at 5:16 AM, deadalnix <deadal...@gmail.com>
wrote:
What is the point of ensuring that the compiler does not
reorder
load/stores if the CPU is allowed to do so ?
Because we can write ASM to tell the CPU not to. We don't
have any
such ability for the compiler right now.
I think the question was: Why would you want to disable
compiler code
motion for loads/stores which are not atomic, as the CPU might
ruin your
assumptions anyway?
The compiler does whatever it takes to ensure sequential
consistency for shared use, including possibly inserting fences
in certain places.
Andrei
How does this have anything to do with deadalnix' question that I
rephrased at all? It is not at all clear that shared should do
this (it currently doesn't), and the question was explicitly
about Walter's statement that shared should disable compiler
reordering, when at the same time *not* inserting barriers/atomic
ops. Thus the »which are not atomic« qualifier in my message.
David
