[llvm] [AMDGPU] Allocate AVRegClass last (PR #146606)

[Jeffrey Byrnes via llvm-commits]

jrbyrnes wrote:

> > Seems like reprioritizing the AVReg class doesn't help this case. But, I'm not sure we should be expecting AV priorities to help.
> 
> My version did the opposite - it made the AV classes the most prioritized

For this test, the result from assigning AV first is the same as the current upstream result. Relative to assigning AV last, we use 2 fewer VGPR, and have the same amount of copies.

The reason why we use two more VGPR with this PR is that when we assign the %av_128, we have some PhysReg interference with some vgpr_32 assignments (specifically interfereing with $v0, $v1 and $v4), thus, the first available PhysReg is $v5:v8. In the default case, we early assign the %av to $v0:v3, and then later we can assign those interfering vgpr_32 to $v4, $v5 and $v6.

This demonstrates that it is better to assign the larger registers first -- at least in this special case where we don't need to use the agprs for %av class. Rather than changing the allocation priority of %av, I think this probably implies that we should only be using %av if we expect to run out of $vgpr. So, preferring the VGPR form of MFMAs unless in the high RP case, and reconstraining any inflations to %av if register pressure is fine.

FWIW -- if we impose constraints s.t. we run out of vgpr, it is better to assign the av last. By doing so, we use fewer vgpr and have less copies:
[bad_ra_stress.mir.txt](https://github.com/user-attachments/files/21337944/bad_ra_stress.mir.txt)

[stress_AVFirst.mir.txt](https://github.com/user-attachments/files/21337947/stress_AVFirst.mir.txt)
[stress_AVLast.mir.txt](https://github.com/user-attachments/files/21337948/stress_AVLast.mir.txt)

So I think we should probably move forward with allocate AV last but also limit our usage of %av to only use if we have excess RP (and constrain to a specific vector register -- vgpr -- if not). 




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