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?

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

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