[llvm] [AMDGPU][Scheduler] Refactor VGPR rematerialization during scheduling (PR #118722)

[Lucas Ramirez via llvm-commits]

lucas-rami wrote:

> I am working on adding post-scheduling rollback functionality to the remat stage and trying to minimize the performance impact in the happy path where no rollbacking is required.

The last commit re-introduces the ability to rollbacks rematerializations when the achievable occupancy estimated by the stage cannot be reached. Unit tests are added for the two possible kind of regions where our heuristics may be optimistic: regions defining rematable register and regions using rematable registers.

In some scenarios rematerializations alone allow us to increase occupancy pre-rescheduling, but the scheduler then does a sub-optimal job and decreases the occupancy again to its pre-stage values. In such cases only the rescheduling is reverted, but rematerializations are not rollbacked. This happens for example in the post-remat reschedule of `bb.2` in `test_occ_7_sink_for_8_occ` (`machine-scheduler-sink-trivial-remats.mir`), where rescheduling lowers the occupancy from 8 to 7. I am looking into  this as a separate issue.

https://github.com/llvm/llvm-project/pull/118722