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

1 files changed, 8 insertions, 1 deletions

diff --git a/utils/TableGen/Record.h b/utils/TableGen/Record.h
index 40c8239b9a..9415109dbb 100644
--- a/utils/TableGen/Record.h
+++ b/utils/TableGen/Record.h
@@ -1220,6 +1220,10 @@ inline raw_ostream &operator<<(raw_ostream &OS, const RecordVal &RV) {
 }
 
 class Record {
+  static unsigned LastID;
+
+  // Unique record ID.
+  unsigned ID;
   std::string Name;
   SMLoc Loc;
   std::vector<std::string> TemplateArgs;
@@ -1227,9 +1231,12 @@ class Record {
   std::vector<Record*> SuperClasses;
 public:
 
-  explicit Record(const std::string &N, SMLoc loc) : Name(N), Loc(loc) {}
+  explicit Record(const std::string &N, SMLoc loc) : 
+    ID(LastID++), Name(N), Loc(loc) {}
   ~Record() {}
   
+  unsigned getID() const { return ID; }
+
   const std::string &getName() const { return Name; }
   void setName(const std::string &Name);  // Also updates RecordKeeper.