[llvm] [TableGen] Make ClassInfo sorting deterministic in AsmMatcherEmitter (PR #172894)

[via llvm-commits]

https://github.com/windsunil created https://github.com/llvm/llvm-project/pull/172894

In AsmMatcherEmitter.cpp, the sorting for ClassInfo currently uses ValueName as the main way to order elements. However, many entries— especially RegisterClass records—often have identical or empty ValueName fields.

When these fields match, the final order in the generated MatchClassKind enums ends up depending on the order in which TableGen first found the records. Since this "discovery order" can change between different build environments, it makes it difficult to get bit-for-bit identical LLVM binaries (like libLLVM).

This patch adds the 'Name' field as a secondary tie-breaker when ValueNames are equal. This ensures a total deterministic ordering, making the output the same regardless of the record discovery order.

I observed these ties in X86 and AArch64 targets, and this change ensures they are now sorted consistently.

Fixes #160293

Hi @efriedma-quic 
I've submitted this PR to address the non-determinism issue discussed in #160293.
I used the tie-breaker approach we talked about. Please let me know if you'd like any changes.

>From 15ea8c6305ef7c28ca3293d1d6042d5f375d9cf3 Mon Sep 17 00:00:00 2001
From: Sunil Dora <sunilkumar.dora at windriver.com>
Date: Thu, 18 Dec 2025 11:17:50 -0800
Subject: [PATCH] [TableGen] Make ClassInfo sorting deterministic in
 AsmMatcherEmitter
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

In AsmMatcherEmitter.cpp, the sorting for ClassInfo currently uses
ValueName as the main way to order elements. However, many entries—
especially RegisterClass records—often have identical or empty
ValueName fields.

When these fields match, the final order in the generated
MatchClassKind enums ends up depending on the order in which TableGen
first found the records. Since this "discovery order" can change
between different build environments, it makes it difficult to get
bit-for-bit identical LLVM binaries (like libLLVM).

This patch adds the 'Name' field as a secondary tie-breaker when
ValueNames are equal. This ensures a total deterministic ordering,
making the output the same regardless of the record discovery order.

I observed these ties in X86 and AArch64 targets, and this change
ensures they are now sorted consistently.

Fixes #160293

Signed-off-by: Sunil Dora <sunilkumar.dora at windriver.com>
Co-authored-by: Alexander Kanavin <alex.kanavin at gmail.com>
---
 llvm/utils/TableGen/AsmMatcherEmitter.cpp | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/llvm/utils/TableGen/AsmMatcherEmitter.cpp b/llvm/utils/TableGen/AsmMatcherEmitter.cpp
index e6085af5aa91e..f614461572530 100644
--- a/llvm/utils/TableGen/AsmMatcherEmitter.cpp
+++ b/llvm/utils/TableGen/AsmMatcherEmitter.cpp
@@ -380,11 +380,13 @@ struct ClassInfo {
     }
 
     // FIXME: We should be able to just return false here, as we only need a
-    // partial order (we use stable sorts, so this is deterministic) and the
-    // name of a class shouldn't be significant. However, some of the backends
-    // accidentally rely on this behaviour, so it will have to stay like this
-    // until they are fixed.
-    return ValueName < RHS.ValueName;
+    // partial order and the name of a class shouldn't be significant.
+    // However, some of the backends accidentally rely on this behaviour.
+    // We sort by ValueName and use Name as a tie-breaker to ensure
+    // deterministic output for binary reproducibility.
+    if (ValueName != RHS.ValueName)
+      return ValueName < RHS.ValueName;
+    return Name < RHS.Name;
   }
 };