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

Hal Finkel via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Oct 11 20:03:11 PDT 2018


hfinkel added a comment.

> Currently, there's sort of a split in the LLVM source code about whether volatile operations are allowed to trap; this resolves that dispute in favor of not allowing them to trap. (This is the opposite of the position I originally took, but thinking about it a bit more it makes sense for the uses we expect.)

I agree. They shouldn't trap.

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



================
Comment at: docs/LangRef.rst:2188
+does not point to memory must not modify any memory that is accessible by
+the module being compiled, and the compiler may assume volatile operations
+do not trap.
----------------
How should we specify the interaction between this and inaccessiblememonly?


Repository:
  rL LLVM

https://reviews.llvm.org/D53184





More information about the llvm-commits mailing list