[PATCH] D12168: Improve the determinism of MergeFunctions

JF Bastien via llvm-commits llvm-commits at lists.llvm.org
Thu Aug 20 13:40:20 PDT 2015


jfb added inline comments.

================
Comment at: lib/Transforms/IPO/MergeFunctions.cpp:159
@@ +158,3 @@
+    uint64_t getNumber(GlobalValue* Global) {
+      auto I = GlobalNumbers.insert({Global, NextNumber});
+      if (I.second)
----------------
Use `std::tie` here, it'll make the code easier to read since you can name `first` and `second`: I had to look up `insert`'s API to figure this out :-)

================
Comment at: lib/Transforms/IPO/MergeFunctions.cpp:460
@@ -418,1 +459,3 @@
+    //assert(FunctionComparator(F, G, GlobalNumbers).compare() == 0 &&
+    //       "The two functions must be equal");
 
----------------
?

================
Comment at: lib/Transforms/IPO/MergeFunctions.cpp:484
@@ -446,3 +483,3 @@
 int FunctionComparator::cmpAPFloats(const APFloat &L, const APFloat &R) const {
-  if (int Res = cmpNumbers((uint64_t)&L.getSemantics(),
-                           (uint64_t)&R.getSemantics()))
+  // TODO: This correctly handles all extant fltSemantics, because they all have
+  // different precisions. This isn't very robust, however, if new types with
----------------
existant?

================
Comment at: lib/Transforms/IPO/MergeFunctions.cpp:489
@@ -449,1 +488,3 @@
+  if (int Res = cmpNumbers(APFloat::semanticsPrecision(SL),
+                           APFloat::semanticsPrecision(SR)))
     return Res;
----------------
Why not also compare min/max exponent here? It seems like you could add `bool operator==(const fltSemantics&, const fltSemantics&)` and use that?

================
Comment at: lib/Transforms/IPO/MergeFunctions.cpp:616
@@ +615,3 @@
+    // for a given input module and host platform.
+    return cmpStrings(SeqL->getRawDataValues(), SeqR->getRawDataValues());
+  }
----------------
I think it would be worth renaming `cmpStrings` to `cmpMem` because that's what `StringRef` does: it ignores null-termination and does `memcmp` based on the declared size.

Could you also add a mergefuncs test that makes sure this is the case: two functions with ConstantDataArray (or vector) which have the same length, same prefix, a null byte, and then different tail. They shouldn't get merged with the current implementation.

================
Comment at: lib/Transforms/IPO/MergeFunctions.cpp:690
@@ -634,1 +689,3 @@
+    // this. This only affects programs which take BlockAddresses and store them
+    // as constants, which is limited to interepreters, etc.
     return cmpNumbers((uint64_t)L, (uint64_t)R);
----------------
Can you `cmpBasicBlocks`?

================
Comment at: lib/Transforms/IPO/MergeFunctions.cpp:695
@@ +694,3 @@
+    DEBUG(dbgs() << "Looking at valueID " << L->getValueID() << "\n");
+    llvm_unreachable("Constant ValueID not recognized.");
+  }
----------------
I think some MSVC versions are sad if you don't have a `return` here. It should be conservative, so not `0`.

================
Comment at: lib/Transforms/IPO/MergeFunctions.cpp:729
@@ +728,3 @@
+    return cmpNumbers(cast<IntegerType>(TyL)->getBitWidth(),
+                      cast<IntegerType>(TyR)->getBitWidth());
+  case Type::VectorTyID: {
----------------
Is `TyR` also known to be `IntegerType` here? I don't think it is.

================
Comment at: lib/Transforms/IPO/MergeFunctions.cpp:731
@@ +730,3 @@
+  case Type::VectorTyID: {
+    VectorType *VTyL = cast<VectorType>(TyL), *VTyR = cast<VectorType>(TyR);
+    if (int Res = cmpNumbers(VTyL->getNumElements(), VTyR->getNumElements()))
----------------
Same here.

================
Comment at: lib/Transforms/IPO/MergeFunctions.cpp:998
@@ +997,3 @@
+  if (int Res = cmpNumbers(L->getDialect(), R->getDialect()))
+    return Res;
+  llvm_unreachable("InlineAsm blocks were not uniqued.");
----------------
No comparison of `getType` and `getFunctionType`?

================
Comment at: lib/Transforms/IPO/MergeFunctions.cpp:999
@@ +998,3 @@
+    return Res;
+  llvm_unreachable("InlineAsm blocks were not uniqued.");
+}
----------------
Same on final return for MSVC.


http://reviews.llvm.org/D12168





More information about the llvm-commits mailing list