Can compiler optimize comparing volatile variable to itself and assume it will be equal? Or it has to read twice this variable and compare the two values it got?

CodePudding user response：

The way I think about volatile variables is that reading from them or writing to them is treated like an I/O function.

A call to an I/O function can never be optimized out, because it has side effects. Nor can a read or write involving a volatile variable be optimized out.

If you code two calls to the same input function, the compiler has to ensure the input function is actually called twice, since it could give different results. In the same way, you can read from a volatile variable twice, and in between the two reads, someone else could change the value of the variable. So the compiler will always emit the instructions to read it twice, whereas with non-volatile variables it can simply assume they're not modified by anyone outside the program.

Again, I/O functions calls can't be reordered, and nor can volatile variable accesses.

CodePudding user response：

C 2018 6.7.3 8 says:

An object that has volatile-qualified type may be modified in ways unknown to the implementation or have other unknown side effects. Therefore any expression referring to [an object with volatile-qualified type] shall be evaluated strictly according to the rules of the abstract machine, as described in 5.1.2.3… What constitutes an access to an object that has volatile-qualified type is implementation-defined.

5.1.2.3 4 says:

… In the abstract machine, all expressions are evaluated as specified by the semantics…

In x == x, where x is a volatile-qualified object, the semantics are that the first x is converted to the value of the object x (by lvalue conversion per 6.3.2.1 2), the second x is converted to its value, and the two values are compared. Converting an object to its value accesses the object, getting the value stored in it.

So the abstract machine accesses x twice. By 6.7.3 8, this evaluation is strict; the actual program must implement the same accesses as the abstract machine, so the value of x must be accessed twice; neither can be optimized away.

The C standard leaves it to the C implementation to define what constitutes an access. But whatever that is, the program must do it twice.