The existing way of managing clustered nodes was done through adding
weak edges between the neighbouring cluster nodes, which is a sort of
ordered queue. And this will be later recorded as `NextClusterPred` or
`NextClusterSucc` in `ScheduleDAGMI`.

But actually the instruction may be picked not in the exact order of the
queue. For example, we have a queue of cluster nodes A B C. But during
scheduling, node B might be picked first, then it will be very likely
that we only cluster B and C for Top-Down scheduling (leaving A alone).

Another issue is:
```
   if (!ReorderWhileClustering && SUa->NodeNum > SUb->NodeNum)
      std::swap(SUa, SUb);
   if (!DAG->addEdge(SUb, SDep(SUa, SDep::Cluster)))
```
may break the cluster queue.

For example, we want to cluster nodes (order as in `MemOpRecords`): 1 3
2. 1(SUa) will be pred of 3(SUb) normally. But when it comes to (3, 2),
As 3(SUa) > 2(SUb), we would reorder the two nodes, which makes 2 be
pred of 3. This makes both 1 and 2 become preds of 3, but there is no
edge between 1 and 2. Thus we get a broken cluster chain.

To fix both issues, we introduce an unordered set in the change. This
could help improve clustering in some hard case.

One key reason the change causes so many test check changes is: As the
cluster candidates are not ordered now, the candidates might be picked
in different order from before.

The most affected targets are: AMDGPU, AArch64, RISCV.

For RISCV, it seems to me most are just minor instruction reorder, don't
see obvious regression.

For AArch64, there were some combining of ldr into ldp being affected.
With two cases being regressed and two being improved. This has more
deeper reason that machine scheduler cannot cluster them well both
before and after the change, and the load combine algorithm later is
also not smart enough.

For AMDGPU, some cases have more v_dual instructions used while some are
regressed. It seems less critical. Seems like test `v_vselect_v32bf16`
gets more buffer_load being claused.

A long time ago (back in 2009) there was a commit 52d4d8244b7c39c5cd
that changed the scheduler to not dirty height/depth when adding or
removing SUnit predecessors when the latency on the edge was zero. That
commit message is claiming that the depth or height isn't affected when
the latency is zero.

As a matter of fact, the depth/height can change even with a zero
latency on the edge. If for example adding a new SUnit A, with zero
latency, but as a predecessor to a SUnit B, then both height of A and
depth of B should be marked as dirty. If for example B has a greater
height than A, then the height of A needs to be adjusted even if the
latency is zero.

I think this has been wrong for many years. Downstream we have had
commit 52d4d8244b7c39c5cd reverted since back in 2016. There is no
motivating lit test for 52d4d8244b7c39c5cd (only an incomplete C level
reproducer in https://github.com/llvm/llvm-project/issues/3613).

After commit 13d04fa560e156797c21f1 there finally appeared an upstream
lit test that shows that we get better code if marking height/depth as
dirty (llvm/test/CodeGen/AArch64/abds.ll).

Patch co-authored by AtariDreams (gfunni234@gmail.com).

Fixes #38037.

[AMDGPU] Update test results to fix build (#92982)

This reverts commit f0d1ae83b046ff0eeffc72a103f7c8b01ad33787.

This commit breaks tests: http://45.33.8.238/linux/138572/step_11.txt

Fix https://github.com/llvm/llvm-project/issues/38037

Identified with misc-include-cleaner.

In SUnit::removePred, N->WeakSuccsLeft is reduced but WeakSuccsLeft is checked.

Reviewed By: kerbowa

Differential Revision: https://reviews.llvm.org/D151311

This change fixes static code analysis errors

Reviewed By: skan

Differential Revision: https://reviews.llvm.org/D149506

This reverts commit 22b23a5213b57ce1834f5b50fbbf8a50297efc8a.

This commit caused the following two build bots to start failing:
https://lab.llvm.org/buildbot/#/builders/216/builds/20322
https://lab.llvm.org/buildbot/#/builders/123/builds/18511

This change fixes static code analysis errors

Reviewed By: skan

Differential Revision: https://reviews.llvm.org/D148912