Compiler magic for preventing memory access re-ordering _by the compiler_ (keywords: memory model, compiler optimisations, memory order)
Cecil Ward
d at cecilward.com
Mon Nov 6 03:40:23 UTC 2017
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?
More information about the Digitalmars-d-learn
mailing list