[PATCH] D53184: [LangRef] Clarify semantics of volatile operations.

[Taylor Cramer via Phabricator via llvm-commits]

cramertj added a comment.

>> Hal brought up the possibility on llvmdev that certain APIs like isSafeToLoadUnconditionally and FindAvailablePtrLoadStore might assume that volatile operations do in fact point to memory; I think we should just treat that as a bug, though.
>  I agree. We should not use the presence of a volatile operation to justify adding other non-volatile accesses to the same address (and, by definition, we can't add other volatile accesses).

Can we then also expand this part of the reference to clarify that optimizers must not change the number of volatile *or* nonvolatile operations to memory which is only accessed via volatile operations (with a note one way or the other WRT whether this includes loads/stores from pointers marked "dereferenceable")?

> Certain memory accesses, such as load’s, store’s, and llvm.memcpy’s may be marked volatile. 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. This is not Java’s “volatile” and has no cross-thread synchronization behavior.




Repository:
  rL LLVM

https://reviews.llvm.org/D53184