Rework PNaCl memory ordering

include/llvm/IR/NaClAtomicIntrinsics.h

Index: include/llvm/IR/NaClAtomicIntrinsics.h
diff --git a/include/llvm/IR/NaClAtomicIntrinsics.h b/include/llvm/IR/NaClAtomicIntrinsics.h
index 680c6440249210d2d1d043b5bd6e5df31d077dd2..5a8352a57d8a304a1b7b92226ac641f31f1ec833 100644
--- a/include/llvm/IR/NaClAtomicIntrinsics.h
+++ b/include/llvm/IR/NaClAtomicIntrinsics.h
@@ -100,6 +100,14 @@ enum MemoryOrder {
   MemoryOrderRelease,
   MemoryOrderAcquireRelease,
   MemoryOrderSequentiallyConsistent,
+  // The following memory order is specific to PNaCl and is used to
+  // support non-C11/C++11 legacy code which uses the __sync_synchronize
+  // GCC-style builtin and the asm("":::"memory") compiler fence
+  // idiom. It's equivalent to MemoryOrderSequentiallyConsistent
+  // surrounded by compiler barriers, which means that in practice is
+  // should prevent reordering of memory accesses to objects which may
+  // escape.
+  MemoryOrderSequentiallyConsistentAll,

[jvoung (off chromium), 2013/08/05 23:21:22]

I guess the thing with having this in the general MemoryOrder enum is that it
becomes available to RMW, etc. which we don't necessarily want?  That is
compared to having a completely separate intrinsic w/ baked in memory order.

[JF, 2013/08/05 23:25:50]

Good point, I could make a separate @llvm.nacl.atomic.synchronization.fence
intrinsic. Any preference on naming?

   MemoryOrderNum // Invalid, keep last.
 };