This seems to be the only place in llvm we directly call qsort. We can replace
this with a call to array_pod_sort. Also minor cleanup of the sorting function.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
Using stable_sort doesn't solve anything here: the input is constructed by iterating over a DenseMap whose key is a pointer.
(If you just want to clean this up without actually changing the algorithm, there's a three-operand overload of array_pod_sort.)
I agree. But using array_pod_sort also does not solve anything since the input order itself is random. Maybe we can specify a stronger sort predicate?
Can you point at the test cases that are failing? This would mean that there are two symbols with the same name, which seems like something that shouldn't happen.
The following 3 tests fail:
LLVM :: CodeGen/ARM/available_externally.ll LLVM :: CodeGen/ARM/darwin-tls.ll LLVM :: CodeGen/ARM/indirect-hidden.ll
I think this is just a result of your predicate being wrong for std::sort (it's also wrong for stable_sort, but there you might get lucky). It wants a bool that's true when the symbol is compares less than, instead of the tristate you have in this change.
I'd prefer to just use array_pod_sort here. It also wants a tristate so just swapping out qsort for array_pod_sort should pass tests.
Any reason for moving this using decl out of the function?