[PATCH] D18775: NFC: make AtomicOrdering an enum class

James Y Knight via llvm-commits llvm-commits at lists.llvm.org
Wed Apr 6 08:20:55 PDT 2016


jyknight added a comment.

I'm a bit wondering what was the point of making it an enum class? It looks like what you were going for is to remove < and > comparisons with the AtomicOrdering values, and to always use more explicit accessors. But, enum class doesn't actually prevent that, right?


================
Comment at: include/llvm/IR/Instructions.h:76
@@ +75,3 @@
+
+/// Returns true if the ordering is stronger than Monotonic (i.e. consume,
+/// acquire, acq_rel, or seq_cst).
----------------
the "i.e."s here seem pretty obvious from the code

================
Comment at: include/llvm/IR/Instructions.h:300
@@ -270,2 +299,3 @@
   void setOrdering(AtomicOrdering Ordering) {
     setInstructionSubclassData((getSubclassDataFromInstruction() & ~(7 << 7)) |
+                               ((unsigned)Ordering << 7));
----------------
This comment is not actually related to your patch:

I notice this code here (and in other cases below) is depending on the AtomicOrdering values fitting in *3* bits, while the code in AtomicSDNode is checking that it fits in *4* bits. That seems an unfortunate discrepency.

================
Comment at: lib/Analysis/MemoryDependenceAnalysis.cpp:521
@@ -520,3 +520,3 @@
       // FIXME: This is overly conservative.
-      if (LI->isAtomic() && LI->getOrdering() > Unordered) {
+      if (LI->isAtomic() && isStrongerThanMonotonic(LI->getOrdering())) {
         if (!QueryInst || isNonSimpleLoadOrStore(QueryInst) ||
----------------
Is this an unintentional change? It used to be enforcing ordering requirements on Monotonic or stronger, not only stronger-than Monotonic.


http://reviews.llvm.org/D18775





More information about the llvm-commits mailing list