8

I have been advised many times that accesses to volatile objects can't be optimised away, however it seems to me as though this section, present in the C89, C99 and C11 standards advises otherwise:

... An actual implementation need not evaluate part of an expression if it can deduce that its value is not used and that no needed side effects are produced (including any caused by calling a function or accessing a volatile object).

If I understand correctly, this sentence is stating that an actual implementation can optimise away part of an expression, providing these two requirements are met:

  • "its value is not used", and
  • "that no needed side effects are produced (including any caused by calling a function or accessing a volatile object)"...

It seems to me that many people are confusing the meaning for "including" with the meaning for "excluding".

Is it possible for a compiler to distinguish between a side effect that's "needed", and a side effect that isn't? If timing is considered a needed side effect, then why are compilers allowed to optimise away null operations like do_nothing(); or int unused_variable = 0;?

If a compiler is able to deduce that a function does nothing (eg. void do_nothing() { }), then is it possible that the compiler might have justification to optimise calls to that function away?

If a compiler is able to deduce that a volatile object isn't mapped to anything crucial (i.e. perhaps it's mapped to /dev/null to form a null operation), then is it possible that the compiler might also have justification to optimise that non-crucial side-effect away?

If a compiler can perform optimisations to eliminate unnecessary code such as calls to do_nothing() in a process called "dead code elimination" (which is quite the common practice), then why can't the compiler also eliminate volatile writes to a null device?

As I understand, either the compiler can optimise away calls to functions or volatile accesses or the compiler can't optimise away either, because of 5.1.2.3p4.

caf
  • 233,326
  • 40
  • 323
  • 462
autistic
  • 1
  • 3
  • 35
  • 80
  • This question is very similar to http://stackoverflow.com/questions/6664471/observable-behaviour-and-compiler-freedom-to-eliminate-transform-pieces-c-co – M.M May 27 '15 at 04:55

2 Answers2

5

I think the "including any" applies to the "needed side-effects" , whereas you seem to be reading it as applying to "part of an expression".

So the intent was to say:

... An actual implementation need not evaluate part of an expression if it can deduce that its value is not used and that no needed side effects are produced .

Examples of needed side-effects include:

  • Needed side-effects caused by a function which this expression calls
  • Accesses to volatile variables

Now, the term needed side-effect is not defined by the Standard. Section /4 is not attempting to define it either -- it's trying (and not succeeding very well) to provide examples.

I think the only sensible interpretation is to treat it as meaning observable behaviour which is defined by 5.1.2.3/6. So it would have been a lot simpler to write:

An actual implementation need not evaluate part of an expression if it can deduce that its value is not used and that no observable behaviour would be caused.

Your questions in the edit are answered by 5.1.2.3/6, sometimes known as the as-if rule, which I'll quote here:

The least requirements on a conforming implementation are:

  • Accesses to volatile objects are evaluated strictly according to the rules of the abstract machine.
  • At program termination, all data written into files shall be identical to the result that execution of the program according to the abstract semantics would have produced.
  • The input and output dynamics of interactive devices shall take place as specified in 7.21.3. The intent of these requirements is that unbuffered or line-buffered output appear as soon as possible, to ensure that prompting messages actually appear prior to a program waiting for input.

This is the observable behaviour of the program.

Answering the specific questions in the edit:

Is it possible for a compiler to distinguish between a side effect that's "needed", and a side effect that isn't? If timing is considered a needed side effect, then why are compilers allowed to optimise away null operations like do_nothing(); or int unused_variable = 0;?

Timing isn't a side-effect. A "needed" side-effect presumably here means one that causes observable behaviour.

If a compiler is able to deduce that a function does nothing (eg. void do_nothing() { }), then is it possible that the compiler might have justification to optimise calls to that function away?

Yes, these can be optimized out because they do not cause observable behaviour.

If a compiler is able to deduce that a volatile object isn't mapped to anything crucial (i.e. perhaps it's mapped to /dev/null to form a null operation), then is it possible that the compiler might also have justification to optimise that non-crucial side-effect away?

No, because accesses to volatile objects are defined as observable behaviour.

If a compiler can perform optimisations to eliminate unnecessary code such as calls to do_nothing() in a process called "dead code elimination" (which is quite the common practice), then why can't the compiler also eliminate volatile writes to a null device?

Because volatile accesses are defined as observable behaviour and empty functions aren't.

Community
  • 1
  • 1
M.M
  • 138,810
  • 21
  • 208
  • 365
  • 1
    Perhaps you could ask a linguist to form a phrase structure tree from that sentence... – autistic May 27 '15 at 04:18
  • well, I think "any" should recall the most recent noun phrase mentioned here, which is the needed side-effects. Certainly it could be better worded, as evinced by the fact that people have read it differently – M.M May 27 '15 at 04:22
  • Very well. Prepare for an update to this question... I'll include functions as well as volatile objects. – autistic May 27 '15 at 04:34
  • I see... 5.1.2.3p2 seems to cover that quite well, though that doesn't explain why `int unused_variable = 0;` can be optimised away when volatile accesses (even to null devices) can't... – autistic May 27 '15 at 05:01
  • @undefinedbehaviour have expanded my answer (hopefully it is now clear why `int unused_variable = 0;` can be optimized away too) – M.M May 27 '15 at 05:07
  • @MattMcNabb This seems controversial to me. The standard's wording puts function calls and `volatile` variables into the **same category** (whatever it is), since it says "including […] function calls and […] volatile object[s]". So, if volatile objects have a needed side effect, then so do function calls. So in this case, is the compiler disallowed to optimize a call too? If the converse is true (i. e. neither volatile objects nor calls have "needed" side effects), then both expressions *can* be optimized away. What gives? (I'm not nitpicking, I'm genuinely confused.) – The Paramagnetic Croissant May 27 '15 at 05:10
  • 1
    @TheParamagneticCroissant It doesn't say that calling any function causes a needed side effect. It says that needed side-effects *which are caused by calling a function* may not be optimized out. An illustrative example would be that if we have `void f() { printf("hello\n"); }`, then a call `f();` may not be optimized out because `f` has a needed side-effect. – M.M May 27 '15 at 05:13
  • The term "needed side-effect" is not defined by the standard but I think the only sensible interpretation is to treat it as "causes observable behaviour" which is defined by 5.1.2.3/6. Section /4 is not defining the term. – M.M May 27 '15 at 05:23
  • @MattMcNabb p2 also helps. If you can find a way to introduce that paragraph into your answer, I'm happy to award this as my favourite until something else crops up (if that happens). – autistic May 27 '15 at 05:41
  • @undefinedbehaviour one step ahead of you – M.M May 27 '15 at 05:51
1

I believe this:

(including any caused by calling a function or accessing a volatile object)

is intended to be read as

(including:

  • any side-effects caused by calling a function; or
  • accessing a volatile variable)

This reading makes sense because accessing a volatile variable is a side-effect.

caf
  • 233,326
  • 40
  • 323
  • 462
  • Fair enough, but you should probably try to focus on what is considered a "*needed* side effect"... – autistic May 27 '15 at 05:03
  • According to 5.1.2.3/2, accessing a volatile variable *is* a side-effect, so I think "accessing a volatile variable" and "side-effects caused by accessing a volatile variable" can be taken as semantically equivalent. – M.M May 27 '15 at 05:06
  • @undefinedbehaviour: Isn't it clear that the two parenthesized side-effects are intended to be non-exhaustive examples of needed side-effects? – caf May 27 '15 at 06:13