Can an ANSI C compiler remove a delay loop?

Question

Consider a while loop in ANSI C whose only purpose is to delay execution:

unsigned long counter = DELAY_COUNT;
while(counter--);

I've seen this used a lot to enforce delays on embedded systems, where eg. there is no sleep function and timers or interrupts are limited.

My reading of the ANSI C standard is that this can be completely removed by a conforming compiler. It has none of the side effects described in 5.1.2.3:

Accessing a volatile object, modifying an object, modifying a file, or calling a function that does any of those operations are all side effects, which are changes in the state of the execution environment.

...and this section also says:

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).

Does this imply that the loop could be optimised out? Even if counter were volatile?

Notes:

1. That this is not quite the same as Are compilers allowed to eliminate infinite loops?, because that refers to infinite loops, and questions arise about when a program is allowed to terminate at all. In this case, the program will certainly proceed past this line at some point, optimisation or not.
2. I know what GCC does (removes the loop for -O1 or higher, unless counter is volatile), but I want to know what the standard dictates.

Answer 1

C standard compliance follows the "as-if" rule, by which the compiler can generate any code that behaves "as if" it was running your actual instructions on the abstract machine. Since not performing any operations has the same observable behaviour "as if" you did perform the loop, it's entirely permissible to not generate code for it.

In other words, the time something takes to compute on a real machine is not part of the "observable" behaviour of your program, it is merely a phenomenon of a particular implementation.

The situation is different for volatile variables, since accessing a volatile counts as an "observable" effect.

Answer 2

Does this imply that the loop could be optimised out?

Yes.

Even if counter were volatile?

No. It would read and write a volatile variable, which has observable behavior, so it must occur.

Answer 3

If the counter is volatile, the compiler cannot legally optimize out the delay loop. Otherwise it can.

Delay loops like this are bad because the time they burn depends on how the compiler generates code for them. Using different optimization options you can achieve different delays, which is hardly what one wants from a delay loop.

For this reason such delay loops should be implemented in assembly language, where the programmer controls the code fully. This typically applies in embedded systems with simple CPUs.

Answer 4

The standard dictates the behavior you see. If you create a dependency tree for DELAY_COUNT you see that it has a modify without use property which means it can be eliminated. This is in reference to the non volatile case. IN the volatile case the compiler cannot use the dependency tree to attempt to remove this variable and as such the delay remains (since volatile means that hardware can change the memory mapped value OR in some cases means "I really need this don't throw it away") In the case you're looking at if labeled volatile it tells the compiler, please don't throw this away it's here for a reason.