Index: lib/Analysis/MemoryDependenceAnalysis.cpp
===================================================================
--- lib/Analysis/MemoryDependenceAnalysis.cpp
+++ lib/Analysis/MemoryDependenceAnalysis.cpp
@@ -371,11 +371,18 @@
   unsigned Limit = BlockScanLimit;
   bool isInvariantLoad = false;
 
-  // Atomic accesses are only a problem if there is an acquire after a release.
-  // See "Compiler testing via a theory of sound optimisations in the C11/C++11
-  //   memory model" in PLDI 2013 for details.
+  // We must be careful with atomic accesses, as they may allow another thread
+  //   to touch this location, cloberring it. Based on the results of
+  //   "Compiler testing via a theory of sound optimisations in the C11/C++11
+  //   memory model" in PLDI 2013, we know that this is only possible if there
+  //   is a release access, followed by an acquire access.
+  // The general idea is that for a discriminating context (i.e. that accesses
+  //   MemLoc) to not be racy, it must synchronize with both the access being
+  //   optimized and the previous one, which requires respectively an acquire
+  //   and a release on this thread.
   // This paper does not prove this result for RMW accesses/fences, so we are
-  // conservative with them.
+  // conservative with them. They are detected as ModRef by the alias analysis,
+  // so this function returns Clobber on them automatically.
   bool HasSeenAcquire = false;
 
   if (isLoad && QueryInst) {
@@ -417,8 +424,10 @@
     // a load depends on another must aliased load from the same value.
     if (LoadInst *LI = dyn_cast<LoadInst>(Inst)) {
       // Atomic loads have complications involved.
-      // Monotonic accesses are not dangerous for this purpose.
-      if ((!LI->isUnordered()) && LI->getOrdering() != Monotonic)
+      // Unordered/Monotonic accesses are not dangerous for this purpose,
+      // and a load cannot be Release or Acquire_Release.
+      if (LI->getOrdering() == Acquire
+              || LI->getOrdering() == SequentiallyConsistent)
         HasSeenAcquire = true;
 
       AliasAnalysis::Location LoadLoc = AA->getLocation(LI);
@@ -477,8 +486,11 @@
 
     if (StoreInst *SI = dyn_cast<StoreInst>(Inst)) {
       // Atomic stores have complications involved.
-      // Monotonic accesses are safe for this purpose.
-      if (HasSeenAcquire && (!SI->isUnordered()) && SI->getOrdering() != Monotonic)
+      // Unordered/Monotonic accesses are not dangerous for this purpose,
+      // and a store cannot be Acquire or Acquire_Release.
+      if (HasSeenAcquire &&
+              (SI->getOrdering() == Release
+               || SI->getOrdering() == SequentiallyConsistent))
         return MemDepResult::getClobber(SI);
 
       // If alias analysis can tell that this store is guaranteed to not modify
@@ -503,25 +515,6 @@
       return MemDepResult::getClobber(Inst);
     }
 
-    // FIXME We are probably too conservative here.
-    if (isa<FenceInst>(Inst)) {
-      return MemDepResult::getClobber(Inst);
-    }
-
-    // FIXME We are probably too conservative here.
-    if (auto RMWI = dyn_cast<AtomicRMWInst>(Inst)) {
-        if (RMWI->getOrdering() != Monotonic) {
-            return MemDepResult::getClobber(Inst);
-        }
-    }
-
-    // FIXME We are probably too conservative here.
-    if (auto CASI = dyn_cast<AtomicCmpXchgInst>(Inst)) {
-        if (CASI->getSuccessOrdering() != Monotonic) {
-            return MemDepResult::getClobber(Inst);
-        }
-    }
-
     // If this is an allocation, and if we know that the accessed pointer is to
     // the allocation, return Def.  This means that there is no dependence and
     // the access can be optimized based on that.  For example, a load could