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

[Hal Finkel via Phabricator via llvm-commits]

hfinkel added a comment.

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

I agree. If we need finer granularity sets of inaccessible state, we can create that and figure out how to attach it at that point.

I think that, in general, we're on the same page. It seems a bit unfortunate that a volatile *load* can modify this inaccessible state. In practice, however, it can (e.g., some hardware uses loads from some address as an automatically-sliding-window over some larger internal register file), and without this, it would be difficult to maintain ordering. We should be explicit about this, however, in the text: volatile loads can modify his inaccessible state (which is consistent with the current implementation: mayWriteToMemory returns true for volatile loads).

Also, I think that we should be explicit about call-graph impacts. volatile accesses may have target-specific side effects, but these don't include calling functions that are part of the module being compiled.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D53184