What optimization could the compiler perform in absence of the "volatile" keyword in the following code?

Question

Following is some code to flash LED's on a Pandaboard when running the Barrelfish operating system. My question is that why don't the LED's flash if the 'volatile' keyword is removed from the definitions of gpio_oe and gpio_dataout.

static volatile uint32_t *gpio_oe = (uint32_t *)(GPIO_BASE + 0x0134);
static volatile uint32_t *gpio_dataout = (uint32_t *)(GPIO_BASE + 0x013C);

void led_flash
{
    // Enable output
    *gpio_oe &= (~(1 << 8));

    // Toggle LED on and off till eternity
    while(true)
    {
      *gpio_dataout ^= (1 << 8);  // Set means LED on; Clear means LED off
       time_delay();  // To give blinking effect
    }
}

I know that volatile needs to be used if the value of a variable can change spontaneously through a source outside the program. But I can't see such a case here. What optimization does the compiler perform that renders the whole while loop for flashing LED's meaningless? And what is the logic behind such optimization, ie. a legit case where such an optimization would make sense?

Answer 1

You also need volatile to force a memory write and order in which generated code would access volatile variables. With regular variables the compiler may decide that the writes are unnecessary and either throw them away or only keep the last one.

Moved from the comments: The compiler may write nothing at all if it sees no reads of the variable, it may even remove the variable.

Answer 2

As far as the compiler can tell, the values *gpio_oe and *gpio_dataout are written but never read. For normal data memory such an access pattern is entirely redundant so can be optimised out. Similarly for locations that are read but never written.

For memory mapped I/O however access to the "memory" location has side effects that the compiler is not aware of. Declaring the location volatile tells the compiler that the location must be explicitly accessed exactly as described by the code.

As well as memory mapped I/O, a similar issue occurs with memory shared between separate threads (RTOS tasks or interrupt handlers for example) since the language is similarly unaware of these contexts.

Embedded.com covers the subject in a number of articles:

• Introduction to the volatile keyword - Nigel Jones
• Place volatile accurately - Dan Saks
• Combining C's volatile and const keywords - Michael Barr