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

[Eli Friedman via Phabricator via llvm-commits]

efriedma added a comment.

Yes, volatile loads and stores access the "same" state as inaccessiblememonly functions, I think.

In general, we have to make sure volatile operations don't get reordered.  This is equivalent to saying that volatile operations read/modify some inaccessible state (something like a list of volatile accesses in the program).  This essentially the same as the language for inaccessiblememonly.

We could say that there are two distinct regions of inaccessible state, one for volatile operations, and one for inaccessiblememonly, but that doesn't seem like a good tradeoff.  inaccessiblememonly is already an approximation for the sake of making it easily usable: inaccessiblememonly calls have a dependency on other, unrelated, inaccessiblememonly calls, even if they don't actually touch the same state.  If there's some intrinsic that's particularly sensitive to this, we can refine alias analysis for that intrinsic, either with a new attribute or a special case written in C++.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D53184/new/

https://reviews.llvm.org/D53184