[PATCH] Refine memory dependence's notion of volatile semantics

[hfinkel at anl.gov]

LGTM.

> One question for reviewers: should a load being volatile change the default handling for a *may* alias load?


No, it should not.

FWIW, LLVM's volatile is even more strict than C's volatile. LLVM's volatile is meaningful on loads, and is specified as:

> The optimizers must not change the number of volatile operations or change their order of execution relative to other volatile operations. The optimizers may change the order of volatile operations relative to non-volatile operations.


Whereas C's volatile says (5.1.2.3):

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


Which is made even more explicit under the specification of assignment semantics 6.5.16:

> An assignment operator stores a value in the object designated by the left operand. An assignment expression has the value of the left operand after the assignment (The implementation is permitted to read the object to determine the value but is not required to, even when the object has volatile-qualified type.)


and, thus, is not really meaningful on loads.


http://reviews.llvm.org/D6901

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/