Replace all sort functions with stable sort

[amin1377]

In this pull request, all sorting functions have been replaced with stable sort to ensure consistency in results across platforms. This adjustment mirrors changes already implemented in the version of VPR used in SPEC benchmarks. The aim of this PR is to minimize discrepancies between SPEC's VPR and the upstream branch.

[amin1377]

QoR comparison on Titan ( I ran the benchmark twice to make sure that the results are consistent)

[vaughnbetz]

Maybe the routing runtime reduction is real due to edge sorting somehow being faster? Please check the rr-graph build times.

I looked at the vtr_reg_strong failure and it is OK: one circuit gets a smaller minimum channel width (stereovision3 which is small) and then gets a longer wirelength. Please look at the other failures to confirm they're OK.

[vaughnbetz]

Code looks fine. Maybe the stable sort leads to a more cache localized set of rr_graph edges (but that would only be possible if we actually had quite a few duplicate edges)?

[heshpdx]

In SPEC CPUv8 we started converting std::partition to std::stable_partition, and also investigating converting std::unordered_map to std::map and std::unordered_set to std::set. Even after all that there is still variation between different implementations of the C++ standard library (gcc vs llvm). Investigations ongoing...

[amin1377]

I think that in VPR's placement and routing, we don't depend on the order of hashed objects. Currently, I'm working on reproducing the discrepancy between gcc-13 and llvm to localize the error. I'll then examine the code to see if such dependency exists. If it does, we also need to address it in the upstream VPR repository.

[vaughnbetz]

Agreed. We definitely shouldn't have such a dependency on the order of hashed objects; if we do it is a bug. @soheilshahrouz found a (relatively rare) non-determinism in the master branch which may indicate someone is hashing on a pointer or some such. Adding him to the conversation in case he has any ideas or can help.

[vaughnbetz]

We should fix the stable sort issue while investigating the other compiler-based output changed (maybe a non-determinism). @amin1377 : can you look at the CI failures and confirm they are benign (hopefully just small circuits with QoR changes)? Please put a report in of what you find so we can hopefully merge this.

[vaughnbetz]

Looks at reg_nightly_1. Failures are 4 QoR failures on small arithmetic and multless const circuits (outside of bounds, but these are tiny designs) and one failure to complete (routing failure?) on a small multless const. Not sure why we had a routing failure; I think that one is worth looking at.

23:34:37 | vtr_reg_nightly_test1/arithmetic_tasks/multless_consts...[Fail]
23:34:37 | [Fail]
23:34:37 | fixed_k6_frac_ripple_N8_22nm.xml/mult_103.v/common vpr_status Task value 'success' does not match golden 'exited with return code 2'

[vaughnbetz]

Updating branch to run CI again.
Amin, it would be good to put a note somewhere in the developer's guide about using stable_sort and stable_partition. Not sure where it should go -- maybe a new section on coding for reproducible results (spec)? I can help write it if you like, but I'd probably get you to put it in markup.