summaryrefslogtreecommitdiffstats
path: root/llvm/docs
diff options
context:
space:
mode:
authorJF Bastien <jfb@google.com>2016-04-06 21:19:33 +0000
committerJF Bastien <jfb@google.com>2016-04-06 21:19:33 +0000
commit800f87a871282713fc5f41d00692b51b2ea6c207 (patch)
treeb7b4323ac6fb5b8737b63ed9efe8af168551dbf7 /llvm/docs
parent31994e2eb670e03ec826002df0ae330db8e6c72c (diff)
downloadbcm5719-llvm-800f87a871282713fc5f41d00692b51b2ea6c207.tar.gz
bcm5719-llvm-800f87a871282713fc5f41d00692b51b2ea6c207.zip
NFC: make AtomicOrdering an enum class
Summary: In the context of http://wg21.link/lwg2445 C++ uses the concept of 'stronger' ordering but doesn't define it properly. This should be fixed in C++17 barring a small question that's still open. The code currently plays fast and loose with the AtomicOrdering enum. Using an enum class is one step towards tightening things. I later also want to tighten related enums, such as clang's AtomicOrderingKind (which should be shared with LLVM as a 'C++ ABI' enum). This change touches a few lines of code which can be improved later, I'd like to keep it as NFC for now as it's already quite complex. I have related changes for clang. As a follow-up I'll add: bool operator<(AtomicOrdering, AtomicOrdering) = delete; bool operator>(AtomicOrdering, AtomicOrdering) = delete; bool operator<=(AtomicOrdering, AtomicOrdering) = delete; bool operator>=(AtomicOrdering, AtomicOrdering) = delete; This is separate so that clang and LLVM changes don't need to be in sync. Reviewers: jyknight, reames Subscribers: jyknight, llvm-commits Differential Revision: http://reviews.llvm.org/D18775 llvm-svn: 265602
Diffstat (limited to 'llvm/docs')
-rw-r--r--llvm/docs/Atomics.rst2
1 files changed, 1 insertions, 1 deletions
diff --git a/llvm/docs/Atomics.rst b/llvm/docs/Atomics.rst
index 112ea23b9e9..ff667480446 100644
--- a/llvm/docs/Atomics.rst
+++ b/llvm/docs/Atomics.rst
@@ -367,7 +367,7 @@ Predicates for optimizer writers to query:
that they return true for any operation which is volatile or at least
Monotonic.
-* ``isAtLeastAcquire()``/``isAtLeastRelease()``: These are predicates on
+* ``isStrongerThan`` / ``isAtLeastOrStrongerThan``: These are predicates on
orderings. They can be useful for passes that are aware of atomics, for
example to do DSE across a single atomic access, but not across a
release-acquire pair (see MemoryDependencyAnalysis for an example of this)
OpenPOWER on IntegriCloud