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

[Jeffrey Byrnes via llvm-commits]

jrbyrnes wrote:

> > The analysis doesn't prove that we will change occupancy through rematerialization -- I think this is a complex problem involving the live regs at the rematerialization point, which may change with scheduling. Because of this, we may want to keep the rollback functionality?
> 
> I completely agree, but my rationale for removing the rollback functionality is that after rescheduling `finalizeGCNRegion` -> `checkScheduling` -> `revertScheduling` can already revert scheduling on a per-region basis if we caused a drop in occupancy or extra spilling to happen, at the cost of a hit to compile-time compared to rollbacking immediately. I also suppose that rescheduling post-remat can improve occupancy/spilling beyond what we can assess at the end of rematerialization. Doing an immediate rollback would make us miss on those potential improvements I think.

revertScheduling doesn't un-materialize the remats. 

It's possible that we satisfy the heuristic via rematerialization, but don't increase occupancy before rescheduling. Post-remat rescheduling may improve occupancy / spilling, but it also may not; I think we should err on the side of not doing the remats as this may introduce regressions.

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

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