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

[Lucas Ramirez via llvm-commits]

lucas-rami wrote:

> revertScheduling doesn't un-materialize the remats.

I did not realize this, thanks. I see the need for potentially rollbacking our decisions.

> If we have reason to believe that we should always try to reschedule after remat, then we should move the remat rollback functionality into revertScheduling

I think we should always try to reschedule since the remat heuristics are only "slightly optimistic". In particular, they are exact in regions where rematerialized registers are simply live-through. My motivating example for this series of changes is a case of LICM bringing many defs inside the pre-header of a grid stripe loop containing the whole kernel (which I think is a fairly common situation), causing a lot of spilling. Most affected regions in such cases are those where rematable registers are live-through.

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.

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