AsmMatcherEmitter: Non-deterministic sorting of ClassInfo may break reproducibility

[sunildora1988]

There are cases where ClassInfo lists in llvm/utils/TableGen/AsmMatcherEmitter.cpp are sorted non-deterministically if ValueName fields are identical. This doesn’t break correctness, but it can cause non-reproducible builds, both at the source and binary level.

The fix is simple: after comparing ValueName, add a tie-break using the Name field so that the sorting is always deterministic. For example:

`- return ValueName < RHS.ValueName;

• if (ValueName != RHS.ValueName)
• return ValueName < RHS.ValueName;
• // All else being equal, we should sort by name, for source and binary reproducibility
• return Name < RHS.Name;`

This ensures that identical ValueNames are always ordered the same way, making builds reproducible. It’s a very low risk change because it doesn’t change the behavior of the matcher, only the order in which classes appear in generated tables.

This issue was originally discussed in [https://reviews.llvm.org/D97477]
but the patch never made it upstream. I’ve seen the same problem in LLVM 21. Should I open a PR to upstream this fix?

[efriedma-quic]

Does this impact the reproducibility of code compiled by LLVM, or just the LLVM binaries themselves?

The FIXME comment says that the sort that uses this comparator is supposed to be a stable sort (like llvm::stable_sort, or std::forward_list::sort). Is that not correct? If it isn't, how hard would it be to change the code to use a stable sort?