Fix non-determinism in DAGISel emitter.
- This manifested as non-determinism in the .inc output in rare cases (when two
distinct patterns ended up being equivalent, which is rather rare). That
meant the pattern matching was non-deterministic, which could eventually mean
the code generator selected different instructions based on the arch.
- It's probably worth making the DAGISel ensure a total ordering (or force the
user to), but the simple fix here is to totally order the Record* maps based
on a unique ID.
- PR4672, PR4711.
Yay:
--
ddunbar@giles:~$ cat ~/llvm.obj.64/lib/Target/*/*.inc | shasum
d1099ff34b21459a5a3e7021c225c080e6017ece -
ddunbar@giles:~$ cat ~/llvm.obj.ppc/lib/Target/*/*.inc | shasum
d1099ff34b21459a5a3e7021c225c080e6017ece -
--
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79846 91177308-0d34-0410-b5e6-96231b3b80d8
diff --git a/utils/TableGen/CodeGenDAGPatterns.cpp b/utils/TableGen/CodeGenDAGPatterns.cpp
index 2f12a6c..f0a8c4d 100644
--- a/utils/TableGen/CodeGenDAGPatterns.cpp
+++ b/utils/TableGen/CodeGenDAGPatterns.cpp
@@ -100,6 +100,9 @@
} // end namespace EEVT.
} // end namespace llvm.
+bool RecordPtrCmp::operator()(const Record *LHS, const Record *RHS) const {
+ return LHS->getID() < RHS->getID();
+}
/// Dependent variable map for CodeGenDAGPattern variant generation
typedef std::map<std::string, int> DepVarMap;