• Cecil Ward (37/37) Nov 05 2017 I have to apologise in advance for a truly dumb question, so
• Michael V. Franklin (4/9) Nov 05 2017 You may be looking for volatileLoad/Store:
• Michael V. Franklin (4/13) Nov 05 2017 Also https://dlang.org/phobos/core_bitop.html#.volatileLoad

Cecil Ward <d cecilward.com> writes:

I have to apologise in advance for a truly dumb question, so 
please be kind.

Is there a magic visible sign (or even one needed) in the D 
language that tells D _compilers_ not to move certain types of 
memory load / store operations forwards or backwards relative to 
other operations when optimising the code so that the order in 
the actual generated code varies from the source code order?

I see the various routines available in the runtime library that 
can generate various sorts of special instructions on CPU x, 
hardware fences/barriers etc. That's not what I'm asking about 
tho. I'm just wondering about how the compilers know how much 
freedom they are allowed in moving stuff forwards/backwards or 
even deleting stupid wasteful memory operations altogether, and 
whether there are any special things that a compiler writer needs 
to spot as being magic in D source code.

If the answer is 'no'/'none', I suppose it could be in part down 
to the fact that the _implementation_ of certain D features by 
compilers make use of various compiler-specific non-D magic 
facilities that a compiler already has anyway due to its modern 
C-implementation heritage? But I don't feel that I've answered my 
question in this way, if a compiler is generally free to re-order 
certain statements or external calls past other external calls or 
special statements. That's a general statement of my ignorance 
about the limits of compilers’ freedom in optimising code, and 
something I urgently need to correct. :-) A completely general 
question, which I should have found an answer to first. (Again, 
please be nice to a poor fool.)

This could be a non-question for all I know, so do forgive my 
ignorance. If calls to certain types of _routines_ whose content 
is not know can not be re-ordered either simply (a) because their 
effects are unknown, or (b) because 'volatile' type declarations 
are used in the implementation, is that merely how things happen 
to work? One further dumb question relating to this: if this is 
meaningful and the answer is case (a) could inlining stuff copied 
out of the runtime library into your own routines then wreck the 
safety, and could LTO-type highly clever whole-program 
optimisation undo safety similarly?

Michael V. Franklin <slavo5150 yahoo.com> writes:

On Monday, 6 November 2017 at 03:40:23 UTC, Cecil Ward wrote:
 Is there a magic visible sign (or even one needed) in the D 
 language that tells D _compilers_ not to move certain types of 
 memory load / store operations forwards or backwards relative 
 to other operations when optimising the code so that the order 
 in the actual generated code varies from the source code order?

You may be looking for volatileLoad/Store:  
https://dlang.org/changelog/2.067.0.html#volatile-load-store

Mike

Michael V. Franklin <slavo5150 yahoo.com> writes:

On Monday, 6 November 2017 at 05:54:00 UTC, Michael V. Franklin 
wrote:
 On Monday, 6 November 2017 at 03:40:23 UTC, Cecil Ward wrote:
 Is there a magic visible sign (or even one needed) in the D 
 language that tells D _compilers_ not to move certain types of 
 memory load / store operations forwards or backwards relative 
 to other operations when optimising the code so that the order 
 in the actual generated code varies from the source code order?

 You may be looking for volatileLoad/Store:  
 https://dlang.org/changelog/2.067.0.html#volatile-load-store

Also https://dlang.org/phobos/core_bitop.html#.volatileLoad

Mike