[llvm] AMDGPU: Add new VA inline asm constraint for AV registers (PR #152665)

[Matt Arsenault via llvm-commits]

arsenm wrote:

> It's a little different from misuse of a constraint in another cases. Using 'a' where only 'v' is allowed is a user error and fill fail at asm. But using 'av' for C and D of MFMA is not an error, yet RA may allocate registers of different types for both and it will also fail in asm.

That is invalid usage of the constraint. It is not applicable to srcC and vdst, and trying to ever use it is user error. You must always use a constraint corresponding to the asm you wrote. It's equivalently invalid to trying to use a 'v' constraint with a scalar input, it just happens that this will often work in this case. This constraint exactly matches the behavior of srcA, srcB, and load/store source and result. In no other context is it correct to use. The assembler will fail if the constraint is abused this way, which is fine. That is a user issue, all of these kinds of issues are deferred assembler errors.

> 
> Why is this needed in the first place? 

Because I need to write tests relevant to AV allocation and writing one that produces a split in just the right way is impossibly difficult. I have to drop to frail MIR tests. We also probably should have operand constraints that exactly match the set of encodable values.

> For example we do not have a 'vs' constraint.

That's essentially how 'r' is treated (although we should probably turn that one into an alias for 'v'). In the normal VALU instruction cases between s and v, you have to worry about violating the constant bus restrictions inside the instruction we can't possibly deal with in the compiler, and the user also cannot deal with. That hazard does not exist in the A+V operand cases, you just need to be consistent with the actual instruction usage 

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